[clang] [Clang] omit parentheses in fold expressions with a single expansion (PR #110761)
Erich Keane via cfe-commits
cfe-commits at lists.llvm.org
Thu Oct 3 15:08:59 PDT 2024
================
@@ -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 at -1 {{because 'false_v<requires (short ts, unsigned short ts) { requires (sizeof (ts) == 2) && (sizeof (ts) == 2); }>'}}
-// expected-note at -2 {{because 'false_v<requires (short ts) { requires (sizeof (ts) == 2); }>' evaluated to false}}
+// expected-note at -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
More information about the cfe-commits
mailing list