sammccall added a comment.
Not sure this is ready for review again, ignore me if not...
I'm still not sure why this is correct in principle. Without that, if someone
finds a misparse 6 months from now I don't know how we determine where to fix
it.
For example, this path is called from
`Parser::isKnownToBeDeclarationSpecifier()` whose contract is `Return true if
we know that we are definitely looking at a decl-specifier... Return false if
it's no a decl-specifier, or we're not sure.` There doesn't seem to be any room
for heuristics, unless we're going to change that contract and audit all the
callers. If this *isn't* a heuristic (it sure looks like one) it needs some
comments on why it's correct.
================
Comment at: clang/test/Parser/recovery.c:105
+ unknown_t a; // expected-error {{unknown type name 'unknown_t'}}
+ unknown_t *b; // expected-error {{unknown type name 'unknown_t'}}
+ unknown_t const *c; // expected-error {{unknown type name 'unknown_t'}}
----------------
this diagnostic is worse than the old one (less accurate).
(I think it's OK to trade off diagnostics quality if it's better on balance,
maybe leave a comment?)
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D137020/new/
https://reviews.llvm.org/D137020
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
