[clang] Attach resource attributes to handle within record, instead of record (PR #101433)

[Joshua Batista via cfe-commits]

================
@@ -280,18 +280,22 @@ void CGHLSLRuntime::annotateHLSLResource(const VarDecl *D, GlobalVariable *GV) {
   const auto *RD = Ty->getAsCXXRecordDecl();
   if (!RD)
     return;
-  const auto *HLSLResAttr = RD->getAttr<HLSLResourceAttr>();
-  const auto *HLSLResClassAttr = RD->getAttr<HLSLResourceClassAttr>();
-  if (!HLSLResAttr || !HLSLResClassAttr)
-    return;
+  // the resource related attributes are on the handle member
+  // inside the record decl
+  for (auto *FD : RD->fields()) {
+    const auto *HLSLResAttr = FD->getAttr<HLSLResourceAttr>();
+    const auto *HLSLResClassAttr = FD->getAttr<HLSLResourceClassAttr>();
+    if (!HLSLResAttr || !HLSLResClassAttr)
+      continue;
 
-  llvm::hlsl::ResourceClass RC = HLSLResClassAttr->getResourceClass();
-  llvm::hlsl::ResourceKind RK = HLSLResAttr->getResourceKind();
-  bool IsROV = HLSLResAttr->getIsROV();
-  llvm::hlsl::ElementType ET = calculateElementType(CGM.getContext(), Ty);
+    llvm::hlsl::ResourceClass RC = HLSLResClassAttr->getResourceClass();
+    llvm::hlsl::ResourceKind RK = HLSLResAttr->getResourceKind();
+    bool IsROV = HLSLResAttr->getIsROV();
+    llvm::hlsl::ElementType ET = calculateElementType(CGM.getContext(), Ty);
 
-  BufferResBinding Binding(D->getAttr<HLSLResourceBindingAttr>());
-  addBufferResourceAnnotation(GV, RC, RK, IsROV, ET, Binding);
+    BufferResBinding Binding(D->getAttr<HLSLResourceBindingAttr>());
+    addBufferResourceAnnotation(GV, RC, RK, IsROV, ET, Binding);
----------------
bob80905 wrote:

It's a great question. With how RWBuffer and  RazterizerOrderedBuffer are implemented, there is exactly one handle, and that handle gets the attributes. I don't believe any future resource object implementations will have multiple handles, or generally, multiple members inside the record decl with the resource attributes.
I am unsure how this interacts with UDTs though. I assume this function is called on decls that have been detected to be resource types, and so this function might be directly called on UDT members that are resources, so there wouldn't be a need to recursively search in the for loop for members within members etc.
@bogner might have an idea for how this works with UDTs? 

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