================
@@ -2249,6 +2283,9 @@ ExprResult Parser::ParseUnaryExprOrTypeTraitExpression() {
else if (getLangOpts().C2y && OpTok.is(tok::kw__Countof))
Diag(OpTok, diag::warn_c2y_compat_keyword) << OpTok.getName();
+ if (OpTok.is(tok::caretcaret))
+ return ParseCXXReflectExpression(OpTok.getLocation());
----------------
Sirraide wrote:
> I'm pretty sure I moved it into `ParseUnaryExprOrTypeTraitExpr` in my fork
> just because a _reflect-expression_ [is formally a
> _unary-expression_](https://eel.is/c++draft/expr#nt:unary-expression).
> Functionally, I don't know of any reason it wouldn't work okay in
> `ParseCastExpression` (and I'm pretty sure I had it there at some point).
Ah no, that function is really just for things that are of the form
`<something> ( <expr> )` like `alignof` (it just so happens that some of those
are *unary-expression*s); you’ll notice that e.g. prefix `++` or `--` are
handled directly in `ParseCastExpression()`.
> Depends how much we care to mirror the grammar into this call structure, I
> suppose.
We do care about that in the AST representation usually, but not in the parser
itself (e.g. binary expressions are also not parsed recursively because ~15
levels of recursion to parse a single integer literal would be rather sad).
https://github.com/llvm/llvm-project/pull/164692
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
