improve error recovery for mistyped "types"

[lattner]

Bugzilla Link	3963
Resolution	FIXED
Resolved on	Mar 12, 2010 00:57
Version	unspecified
OS	All

Extended Description

Consider something like this where clang doesn't know foo_t is a type:

static foo_t x = 4;

we emit:

t2.c:2:14: error: invalid token after top level declarator
static foo_t x = 4;
^
and then errors at every use of X because it wasn't declared. Similarly for things like "static foo_t *X etc.

In this case, the parser thinks it is seeing a declaration of a variable named foo_t that is implicit int. In this case (when it is in implicit int mode) it should do lookahead to see if the non-type token (which it thinks is the identifier) is followed immediately by something that is not valid, e.g. another identifier, a *, a &, etc. In this case, it should recover by parsing foo_t as a broken type. This will lead to a much better diagnostic and will squeltch the chain of bogus diagnostics at uses of X.

[lattner]

related to rdar://6759604

[lattner]

FWIW, GCC is even worse at this sort of thing, for the first example, we get:

t2.c:2: error: syntax error before ‘x’
t2.c:2: warning: data definition has no type or storage class

OTOH, it does realize we are declaring x, so later uses of it are correctly parsed and ignored (it makes an invalid decl).

In GCC C++ mode, this is particularly painful. For example, if you mistype a type, something like this:

ComplexPairTy VisitUnaryPlus (const UnaryOperaotr *E) {

We end up getting:

CGComplexExpr.cpp:77: error: expected ',' or '...' before '*' token
CGComplexExpr.cpp:77: error: ISO C++ forbids declaration of 'UnaryOperaotr' with no type
CGComplexExpr.cpp: In member function 'ComplexPairTy::ComplexExprEmitter::VisitUnaryPlus(int)':
CGComplexExpr.cpp:78: error: 'E' was not declared in this scope
... and a chain of other problems...

This is gross spew for just typoing UnaryOperator.

[lattner]

Basic case fixed here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090406/015412.html

[lattner]

In fact, I think that this fixes this whole issue:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090406/015412.html

On:
static foo_t x = 4;

We now produce:

t2.c:1:8: error: unknown type name 'foo_t'
static foo_t x = 4;
^

FWIW, GCC 4.0 produces:
t2.c:1: error: syntax error before ‘x’
t2.c:1: warning: data definition has no type or storage class

And GCC 4.2 produces:
t2.c:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘x’