[clang] [lldb] [clang] implement CWG1980 and CWG2064: instantiation-dependency improvements (PR #190495)

Aaron Ballman via cfe-commits cfe-commits at lists.llvm.org
Fri Jul 31 04:27:22 PDT 2026


================
@@ -406,39 +406,41 @@ namespace PR42362 {
 namespace QualConv {
   int *X;
   template<const int *const *P> void f() {
-    using T = decltype(P);
-    using T = const int* const*;
+    using T = decltype(P);       // expected-note  {{previous definition}}
+    using T = const int* const*; // expected-error {{redefinition with different types ('const int *const *' vs 'decltype(P)' (aka 'const int *const *'))}}
   }
   template void f<&X>();
 
   template<const int *const &R> void g() {
-    using T = decltype(R);
-    using T = const int *const &;
+    using T = decltype(R);        // expected-note  {{previous definition}}
+    using T = const int *const &; // expected-error {{redefinition with different types ('const int *const &' vs 'decltype(R)' (aka 'const int *const &'))}}
   }
   template void g<(const int *const&)X>();
 }
 
 namespace FunctionConversion {
   struct a { void c(char *) noexcept; };
   template<void (a::*f)(char*)> void g() {
-    using T = decltype(f);
+    using T = decltype(f);        // expected-note  {{previous definition}}
     using T = void (a::*)(char*); // (not 'noexcept')
+    // expected-error at -1 {{redefinition with different types ('void (a::*)(char *)' vs 'decltype(f)' (aka 'void (a::*)(char *)'))}}
   }
   template void g<&a::c>();
 
   void c() noexcept;
   template<void (*p)()> void h() {
-    using T = decltype(p);
+    using T = decltype(p);// expected-note  {{previous definition}}
     using T = void (*)(); // (not 'noexcept')
+    // expected-error at -1 {{redefinition with different types ('void (*)()' vs 'decltype(p)' (aka 'void (*)()'))}}
   }
   template void h<&c>();
 }
 
 namespace VoidPtr {
   // Note, this is an extension in C++17 but valid in C++20.
   template<void *P> void f() {
-    using T = decltype(P);
-    using T = void*;
+    using T = decltype(P); // expected-note  {{previous definition}}
+    using T = void*;       // expected-error {{redefinition with different types ('void *' vs 'decltype(P)' (aka 'void *'))}}
----------------
AaronBallman wrote:

> Yeah, I was thinking about printing the diagnostics in a way that puts a light spot on this distinction, without going too far out of our way to explain C++ standardese, which is not something we do in diagnostics.
> 
> So something like:
> 
> ```
> error: redefinition with non-equivalent types ('const int *const *' vs 'decltype(P)')
> ```
> 
> And then for the specific case where the types are the 'same type', we add a note:
> 
> ```
> note: even though these are the same types ('const int *const *'), they are not equivalent for declarative purposes
> ```
> 
> Or we could somehow incorporate that explanation in the first diagnostic.

I'd love to see is the diagnostics engine assert that it never, ever, ever prints `'thing' vs 'thing'` -- if we put something in single quotes in a diagnostic, it's a syntax element so any time we see `vs` and it's the same syntax element on either side (paying attention to the aka form for type aliases), it's a bug in Clang because users can't make sense of that.

I don't think we can land these changes as-is; we've kicked this can down the road for too long IMO.

Your idea with a note is a pretty interesting one, but I'd still like to hear from inexperienced users whether it makes any sense. "not equivalent for declarative purposes" is really weird because:
```
const int * const *P;

void func(const int * const *P);
void func(decltype(P));
```
are equivalent for declarative purposes.

In my ignorance of how WG21 arrived at this solution, I can't help but wonder if they got it wrong when we end up in a situation like this. I certainly don't feel excited about being the first to implement these DRs: https://godbolt.org/z/behGjfKE7 and given the diagnostic behavior under discussion, I think we need a better solution before we inflict this on users.

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


More information about the cfe-commits mailing list