[clang] [clang] Fix address spaces on prvalue (PR #221233)

[Tom Honermann via cfe-commits]

================
@@ -7682,9 +7682,8 @@ PerformConstructorInitialization(Sema &S,
 
     CurInit = S.CheckForImmediateInvocation(
         CXXTemporaryObjectExpr::Create(
-            S.Context, CalleeDecl,
-            Entity.getType().getNonLValueExprType(S.Context), TSInfo,
-            ConstructorArgs, ParenOrBraceRange, HadMultipleCandidates,
+            S.Context, CalleeDecl, Entity.getType().getNonReferenceType(),
+            TSInfo, ConstructorArgs, ParenOrBraceRange, HadMultipleCandidates,
----------------
tahonermann wrote:

Thank you, and sorry I missed that. This turned out to be really interesting.

[Section 3.3.4, "Member function qualifier" of the C++ for OpenCL specification](https://www.khronos.org/opencl/assets/CXX_for_OpenCL.html#addrspace-member-function-qualifiers) explicitly allows for member functions to have address space qualifiers. I wasn't aware of this. Clang supports this, but only for the keyword forms of the OpenCL address space qualifiers. See https://godbolt.org/z/cWfK9GjYc.

We aren't the first to discover this disparity. See https://discourse.llvm.org/t/rfc-solution-for-preserving-the-address-space-of-this-in-c-methods/50526. That discussion didn't reach a conclusion. Richard Smith suggested that deducing this could eventually provide a solution for overloading based on the address space of the implicit object and indeed that does work, but it requires C++23. See https://godbolt.org/z/6excW14PP. (I couldn't test C++ for OpenCL in this case because there does not appear to be a way to specify an alternate C++ standard version when compiling for C++ for OpenCL). I find myself agreeing with Anastasia's conclusion; the method qualifiers approach is quite appealing.

Since we don't intend (so far) to provide keyword forms of the SYCL address space attributes, I think this is something we should fix for consistency. But not as part of this PR and probably not in the immediate future. If you agree, I'll file a new issue to track doing that work.

I'd still like to think a bit about how address space qualifiers should apply to temporary materialization.

While studying the history here, I came across a number of related open github issues that indicate others have also wrestled with some of these concerns in the past.
- https://github.com/llvm/llvm-project/issues/5162
- https://github.com/llvm/llvm-project/issues/198703
- https://github.com/llvm/llvm-project/issues/42641

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