[clang] [HLSL] Fix resource wrapper declaration (PR #125718)

[Justin Bogner via cfe-commits]

bogner wrote:

> 1. If/when we support separate compilation, the user-facing exported "resource" object will be the resource wrapper, not the handle, so that indicates to me we should probably have the wrappers being public.

Depending on which aspect of separate compilation you mean, there are a couple of things to note here:
1. For linking DXIL modules (ie, the "lib" profile), these wrappers are irrelevant - we'll create the appropriate globals in lowering
2. For linking LLVM IR modules containing HLSL programs, we probably don't want to make these unequivocally public *or* internal - a resource that's exported should be public, sure, but that IMO should be opt-in, not opt-out. The fact that these are always public today whether or not they need to be causes issues in both the SPIR-V and DirectX backends. In this case, presumably the linking phase would internalize the globals after linking much like LTO does in C/C++ workflows.

> 2. It feels wrong to do this in CodeGen. It seems like we should be identifying an appropriate storage class in Sema such that we assign the correct linkage automatically.

I'll defer to you on this point, but that does sound pretty reasonable.



https://github.com/llvm/llvm-project/pull/125718