================
@@ -980,7 +980,7 @@ Decl *Parser::ParseStaticAssertDeclaration(SourceLocation
&DeclEnd) {
if (getLangOpts().CPlusPlus11) {
for (unsigned I = 0;; ++I) {
const Token &T = GetLookAheadToken(I);
- if (T.is(tok::r_paren))
+ if (T.isOneOf(tok::r_paren, tok::semi, tok::eof))
----------------
a-tarasyuk wrote:
@AaronBallman, thanks for the feedback. My first thought was to handle it in
Sema. The parser's lookahead determines how to parse the `static_assert`
message, and for malformed input like `"";)`, it seems to classify it as an
expression
https://github.com/llvm/llvm-project/blob/3a56470a0ee68b26ffe93f5079de58ed22f5dc18/clang/lib/Parse/ParseDeclCXX.cpp#L979-L990
But later Sema still assumes a direct `StringLiteral` message must be
unevaluated:
https://github.com/llvm/llvm-project/blob/bbd69eec1d68492a2ddca3a0dfc02681a84088fe/clang/lib/Sema/SemaDeclCXX.cpp#L17962-L17969
https://github.com/llvm/llvm-project/blob/bbd69eec1d68492a2ddca3a0dfc02681a84088fe/clang/lib/Sema/SemaDeclCXX.cpp#L17791-L17793
My understanding is that the malformed input is routed through the expression
path during parser recovery, but the crash occurs because `EvaluateAsString`
still assumes that a direct `StringLiteral` message here must be unevaluated.
I'm wondering whether the preferred approach is to adjust the parser lookahead
or to make the `static_assert` message validation in Sema more robust for
recovery cases. @AaronBallman WDYT? Thanks
https://github.com/llvm/llvm-project/pull/187859
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits