================
@@ -36,7 +36,7 @@ using r1i2 = r1<char>; // expected-error {{constraints not
satisfied for class t
template<typename... Ts> requires
false_v<requires (Ts... ts) {requires ((sizeof(ts) == 2) && ...);}>
// expected-note@-1 {{because 'false_v<requires (short ts, unsigned short ts)
{ requires (sizeof (ts) == 2) && (sizeof (ts) == 2); }>'}}
-// expected-note@-2 {{because 'false_v<requires (short ts) { requires (sizeof
(ts) == 2); }>' evaluated to false}}
+// expected-note@-2 {{because 'false_v<requires (short ts) { requires sizeof
(ts) == 2; }>' evaluated to false}}
----------------
erichkeane wrote:
So there is no reason that shouldn't still work fine, right? The AST is
already 'set', other than the instantiated items, so no 'reparsing' can happen
where the paren expr would matter, as the decltype would already be set as to
whether it is a expr or type based variant, right? Though it is the one I'm
least sure about.
The only thing I could come up with that this MIGHT cause an issue (which, not
ruling out the Decltype above!), is a case where we do a ast-print, and
re-parse. But this requires our ast-print to produce 'compile-able code',
which isn't necessarily the case anyway. Also, to re-parse somehow a template
instantiation.
THOUGH, looking back at `ActOnDecltypeExpression` (called when transforming the
`DecltypeType`, there IS a check for the `ParenExpr`, so I think you've found a
reason we shouldn't do this. It seems wasteful to make `ParenExpr` store a bit
for this just for hte diagnostic, but hopefully this will be useful for
something else in the future, but I think we HAVE to.
https://github.com/llvm/llvm-project/pull/110761
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
