[PATCH] D137020: [clang][AST] Handle variable declaration with unknown typedef in C

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.


================
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'}}
----------------
sammccall wrote:
> aaron.ballman wrote:
> > urazoff wrote:
> > > sammccall wrote:
> > > > 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?)
> > > Just to mention, this is exact behavior of clang for C++.
> > > this diagnostic is worse than the old one (less accurate).
> > 
> > Less accurate how? It went from `use of undeclared identifier 'unknown_t'` to `unknown type name 'unknown_t'` and that seems accurate to me given that the undeclared identifier is written in a type position.
> It *could* be a type position, or it could be an operand of multiplication - because the identifier is unresolved, we don't know.
> 
> (We could discount the possibility it's a multiplication expression because the result would be discarded, but AFAICT that's not actually what's happening and it'll fire in other cases).
> 
> Regardless, this seems OK to me (especially given we already make this guess for C++!)
Ahhh okay, I see what you mean, thanks! I guess I've never seen a discarded multiplication in real world code, so my assumption was there's very little chance this diagnostic is less accurate instead of more accurate. Same goes for `Foo & Bar` which could be a bitwise AND or a declaration of reference in C++.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137020/new/

https://reviews.llvm.org/D137020