[Clang] Instantiate variables referenced in decltype with an undeduced type.

[cor3ntin]

Fixes #160497
Fixes #56652
Fixes #116319
Fixes #161196

[llvmbot]

@llvm/pr-subscribers-clang

Author: Corentin Jabot (cor3ntin)

Changes

Fixes #160497

---

Full diff: https://github.com/llvm/llvm-project/pull/161231.diff

3 Files Affected:

• (modified) clang/docs/ReleaseNotes.rst (+1)
• (modified) clang/lib/Sema/SemaExpr.cpp (+3-2)
• (modified) clang/test/SemaCXX/decltype.cpp (+30)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 270b5d336eba7..3ff40f98334ca 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -432,6 +432,7 @@ Bug Fixes to C++ Support
 - Fix an assertion failure when taking the address on a non-type template parameter argument of
   object type. (#GH151531)
 - Suppress ``-Wdouble-promotion`` when explicitly asked for with C++ list initialization (#GH33409).
+- Correctly deduced return types in ``decltype`` expressions. (#GH160497)
 
 Bug Fixes to AST Handling
 ^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index 3b267c1b1693d..3302bfce193a2 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -20108,8 +20108,9 @@ static void DoMarkVarDeclReferenced(
   bool NeededForConstantEvaluation =
       isPotentiallyConstantEvaluatedContext(SemaRef) && UsableInConstantExpr;
 
-  bool NeedDefinition =
-      OdrUse == OdrUseContext::Used || NeededForConstantEvaluation;
+  bool NeedDefinition = OdrUse == OdrUseContext::Used ||
+                        NeededForConstantEvaluation ||
+                        Var->getType()->isUndeducedType();
 
   assert(!isa<VarTemplatePartialSpecializationDecl>(Var) &&
          "Can't instantiate a partial template specialization.");
diff --git a/clang/test/SemaCXX/decltype.cpp b/clang/test/SemaCXX/decltype.cpp
index 739485b57a3ec..971cf5132d4d5 100644
--- a/clang/test/SemaCXX/decltype.cpp
+++ b/clang/test/SemaCXX/decltype.cpp
@@ -170,3 +170,33 @@ class conditional {
 // FIXME: The diagnostics here are produced twice.
 void foo(conditional<decltype((1),int>) {  // expected-note 2 {{to match this '('}} expected-error {{expected ')'}} expected-note 2{{to match this '<'}}
 } // expected-error {{expected function body after function declarator}} expected-error 2 {{expected '>'}} expected-error {{expected ')'}}
+
+
+namespace GH160497 {
+
+template <class> struct S {
+    template <class>
+    inline static auto mem =
+    [] { static_assert(false); // expected-error {{static assertion failed}} \
+        // expected-note {{while substituting into a lambda expression here}}
+        return 42;
+    }();
+};
+
+using T = decltype(S<void>::mem<void>);
+ // expected-note@-1 {{in instantiation of static data member 'GH160497::S<void>::mem<void>' requested here}}
+
+namespace N1 {
+
+template<class>
+struct S {
+  template<class>
+  inline static auto mem = 42;
+};
+
+using T = decltype(S<void>::mem<void>);
+
+T y = 42;
+
+}
+}

[erichkeane]

I actually wonder if this should be isUndeducedAutoType. This ends up doing a type visitor to check if there is ANY 'auto' in the type (GetContainedDeducedTypeVisitor).

Do we expect this to work with an auto* return type to the lambda, etc? I actually lean towards YES, but would love a test or two?

[zygoloid]

Can we condition this check on TSK != TSK_Undeclared? As it stands, every time any variable is mentioned we'll walk its type looking for auto, which sounds quite expensive, given how common name references to variables are.

[zyn0217]

+1, note that we do have the same check inside this function

  if (UsableInConstantExpr || Var->getType()->isUndeducedType()) {

So it would be at least worth combining it into a bool variable.

@cor3ntin

[cor3ntin]

I just saw that, I'll make a PR

[erichkeane]

The test ONLY tests auto as a return, but the change itself is ANY type containing an undeduced type. Perhaps there is value in a -> auto *, ->auto [], function pointer return, and `pack expansion' type?

[zwuis]

Does this patch fix #161196?

[cor3ntin]

@zwuis Yes, thanks!