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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
