================
@@ -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@-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@-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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
