forked from OSchip/llvm-project
Improve error recovery in C++: when we hit 'implicit int' cases in C++,
these are usually because the parser was thoroughly confused. In addition to typing the value being declared as an int and hoping for the best, we mark the value as invalid so we don't get chains of errors when it is used downstream. In C, implicit int actually is valid, so typing the thing as int is good and marking it invalid is bad. :) llvm-svn: 74266
This commit is contained in:
parent
2dbc6476cb
commit
d86a13e02e
|
@ -200,10 +200,9 @@ bool Sema::CheckInitializerTypes(Expr *&Init, QualType &DeclType,
|
|||
|
||||
if (InitEntity)
|
||||
return Diag(InitLoc, diag::err_cannot_initialize_decl)
|
||||
<< InitEntity << (int)(Init->isLvalue(Context) == Expr::LV_Valid)
|
||||
<< Init->getType() << Init->getSourceRange();
|
||||
else
|
||||
return Diag(InitLoc, diag::err_cannot_initialize_decl_noname)
|
||||
<< InitEntity << (int)(Init->isLvalue(Context) == Expr::LV_Valid)
|
||||
<< Init->getType() << Init->getSourceRange();
|
||||
return Diag(InitLoc, diag::err_cannot_initialize_decl_noname)
|
||||
<< DeclType << (int)(Init->isLvalue(Context) == Expr::LV_Valid)
|
||||
<< Init->getType() << Init->getSourceRange();
|
||||
}
|
||||
|
@ -211,7 +210,7 @@ bool Sema::CheckInitializerTypes(Expr *&Init, QualType &DeclType,
|
|||
// C99 6.7.8p16.
|
||||
if (DeclType->isArrayType())
|
||||
return Diag(Init->getLocStart(), diag::err_array_init_list_required)
|
||||
<< Init->getSourceRange();
|
||||
<< Init->getSourceRange();
|
||||
|
||||
return CheckSingleInitializer(Init, DeclType, DirectInit, *this);
|
||||
}
|
||||
|
|
|
@ -121,16 +121,18 @@ QualType Sema::ConvertDeclSpecToType(const DeclSpec &DS,
|
|||
if (DeclLoc.isInvalid())
|
||||
DeclLoc = DS.getSourceRange().getBegin();
|
||||
|
||||
if (getLangOptions().CPlusPlus && !getLangOptions().Microsoft)
|
||||
if (getLangOptions().CPlusPlus && !getLangOptions().Microsoft) {
|
||||
Diag(DeclLoc, diag::err_missing_type_specifier)
|
||||
<< DS.getSourceRange();
|
||||
else
|
||||
|
||||
// When this occurs in C++ code, often something is very broken with the
|
||||
// value being declared, poison it as invalid so we don't get chains of
|
||||
// errors.
|
||||
isInvalid = true;
|
||||
} else {
|
||||
Diag(DeclLoc, diag::ext_missing_type_specifier)
|
||||
<< DS.getSourceRange();
|
||||
|
||||
// FIXME: If we could guarantee that the result would be well-formed, it
|
||||
// would be useful to have a code insertion hint here. However, after
|
||||
// emitting this warning/error, we often emit other errors.
|
||||
}
|
||||
}
|
||||
|
||||
// FALL THROUGH.
|
||||
|
|
|
@ -189,8 +189,7 @@ class foo {
|
|||
foo<somens:a> a2; // expected-error {{unexpected namespace name 'somens': expected expression}} \
|
||||
expected-error {{C++ requires a type specifier for all declarations}}
|
||||
|
||||
// FIXME: This is bogus, there is no int here!
|
||||
somens::a a3 = a2; // expected-error {{cannot initialize 'a3' with an lvalue of type 'int'}}
|
||||
somens::a a3 = a2;
|
||||
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue