In D94337#2496329, @tra wrote:

We were talking about the case where clang can't expand CUDA-specific macros.

Somehow I totally forgot about or missed this context.

In D94337#2491825, @tra wrote:

'Works' is not exactly the same as 'works correctly'. This example makes a() look like a regular host function, instead of the kernel, and that affects how the rest of the TU get parsed.
I.e. you'll have further errors if somewhere down below the file has a<<<1,1>>>(). Similar story with ignoring __host__ and __device__ attributes -- that may lead to various overload resolution errors, or reporting conflicting redeclarations/redefinitions for the perfectly valid host/device function overloads. The list goes on.

Added CUDAHeader_DEVICE to propery handle split compilation

In D94337#2491515, @tra wrote:

Does it make sense?

Yep, most of what your saying makes sense to me. Thanks for taking the time to review this.

In D94337#2490828, @tra wrote:

The problem is that just telling compiler that the header is a CUDA source is not sufficient. Clang relies on a lot of CUDA SDK headers in order to make the standard CUDA things like __host__, 'device', threadIdx, etc work. For the CUDA source files clang pre-includes a lot of headers. I'm not quite sure what clang would be supposed to do when it's given a .cuh as an input. If we pre-include the CUDA headers as we do for .cu compilation, we'll get way more of the preprocessed output than the user would likely expect. If we do not pre-include CUDA headers, we'll not get CUDA macros expanded and the output would not be suitable to pass on to the further compilation. On one hand it does not make things worse. On the other, it does not make them better, either. If anything, Clang not recognizing CUDA headers on their own is probably better than accepting them and producing invalid output.

Perhaps I'm missing something. Do you have specific use case in mind for this change?

Just to be clear, this is currently a WIP - it would still be good if someone took a look at this because I don't know if
this approach makes any sense.

Fixed completion extension bug

Fused commits so CI passes???

Oops didn't mean to open new revision.

Fixed some missing applications

I haven't added any tests for this change. This is my first commit, so I am not sure how to write a test or what tests are appropriate.