[PATCH] D113752: [Parse] Use empty RecoveryExpr when if/while/do/switch conditions fail to parse
Sam McCall via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Dec 30 06:14:03 PST 2021
sammccall marked 6 inline comments as done.
sammccall added a comment.
In D113752#3188486 <https://reviews.llvm.org/D113752#3188486>, @hokein wrote:
> since we're now preserving more invalid code, we should check whether const-evaluator is cable of handling these newly-added invalid case.
>
> - the follow case will result an value-dependent violation, the fix would be to handle value-dependent condition in `EvaluateSwitch` (`clang/lib/AST/ExprConstant.cpp`)
Great catch, thanks!
I added constant-evaluation to ensure we don't crash for all the varieties of broken loops I could think of.
They're in `SemaCXX/constexpr-function-recovery-crash.cpp` which seems to be very similar. Maybe slightly misplaced as really we're testing AST/ExprConstant.
================
Comment at: clang/test/Parser/cxx0x-attributes.cpp:155
alignas(4 ns::i; // expected-note {{to match this '('}}
+ // expected-error at -1 {{expected ';' after do/while}}
} // expected-error 2{{expected ')'}} expected-error {{expected expression}}
----------------
hokein wrote:
> This looks like a bogus diagnostic, but I think it is ok, as this is a poor-recovery case for clang already -- IIUC, the do-while statement range claims to the `}` on Line56.
>
> this is a case which can be improved by our bracket-matching repair :)
Right. My understanding is the diagnostic is bogus if you put both missing `)`s before the semicolon, but clang is noticing them/implicitly inserting them before the `}`.
The code is horribly mangled here in any case, I'm not sure what diagnostic I'd want as a user really.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D113752/new/
https://reviews.llvm.org/D113752
More information about the cfe-commits
mailing list