Always treat CCCL as system headers

[miscco]

There are users that build with stronger warning levels that we test against or use newer compilers that added warnings

In that case, their build might fail due to warnings emitted by a cccl header.

To work around this user issue we allow users to define CCCL_AS_SYSTEM_HEADER to silence all warnings originating from our headers

Fixes #527

[jrhemstad]

To work around this user issue we allow users to define CCCL_AS_SYSTEM_HEADER to silence all warnings originating from our headers

This should be opt out, not opt in.

[miscco]

This construction here is needed to keep preexisting behavior.

I decided to overwrite the old _LIBCUDACXX_DISABLE_PRAGMA_MSVC_WARNING and _LIBCUDACXX_DISABLE_PRAGMA_GCC_SYSTEM_HEADER behavior in case of CCCL_AS_SYSTEM_HEADER

Shout if you disagree

[gevtushenko]

A few comments:

suggestion: I prefer self-sufficient headers. Most of the changes add macro to the header containing only CUB includes. It's difficult to prove that the include chain will lead us to libcu++ config. It happens to do so due to namespace macro, but it's implicit. Also, in Thrust, you've included libcu++ config into Thrust config, but this is not done for CUB.

important: this PR has to add _CCCL_NO_SYSTEM_HEADER definition to Thrust/CUB tests and examples before it's merged.

suggestion: macro was not added to the following headers:

• cub/cub/detail/exec_check_disable.cuh
• cub/cub/detail/detect_cuda_runtime.cuh
• thrust/thrust/detail/memory_wrapper.h
• thrust/thrust/detail/numeric_wrapper.h
• thrust/thrust/detail/config/simple_defines.h
• thrust/thrust/detail/algorithm_wrapper.h
• thrust/thrust/detail/preprocessor.h
• thrust/thrust/version.h

[miscco]

A few comments:

suggestion: I prefer self-sufficient headers. Most of the changes add macro to the header containing only CUB includes. It's difficult to prove that the include chain will lead us to libcu++ config. It happens to do so due to namespace macro, but it's implicit. Also, in Thrust, you've included libcu++ config into Thrust config, but this is not done for CUB.

I intentionally tried to keep the changes minimal. Thats why in CUB I only added the include to cub/version.cuh because that is transitively included everywhere. I can move it to config.cuh though

important: this PR has to add _CCCL_NO_SYSTEM_HEADER definition to Thrust/CUB tests and examples before it's merged.

That will not work. As it stands, thrust and cub currently require libcu++ as system header because of deprecated symbols. I am absolutely unclear why but I believe that is for another day

suggestion: macro was not added to the following headers:

• cub/cub/detail/exec_check_disable.cuh
• cub/cub/detail/detect_cuda_runtime.cuh
• thrust/thrust/detail/memory_wrapper.h
• thrust/thrust/detail/numeric_wrapper.h
• thrust/thrust/detail/config/simple_defines.h
• thrust/thrust/detail/algorithm_wrapper.h
• thrust/thrust/detail/preprocessor.h
• thrust/thrust/version.h

I was unsure about the wrapper headers and headers that are purely defining macros, but I can happily add the Macro and the config include to those headers as well

[gevtushenko]

That will not work. As it stands, thrust and cub currently require libcu++ as system header because of deprecated symbols. I am absolutely unclear why but I believe that is for another day

If it's problematic, I'm fine merging this PR once remaining comments are addressed. But before doing that, please, file an issue, link it here, and prioritize disabling the macro in our tests.

[jrhemstad]

@miscco in order to add a sanity test that these changes work as expected, I think we should update the example_project to add some aggressive warning flags. This will verify that anyone linking against the cmake target won't get warnings from CCCL headers. Perhaps @cliffburdick can share the warning flags he was using that led to the warnings he saw.

[griwes]

Checked mainly the implementation of the macros, it seems correct.