| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
ptr-operators, and use"
This seems to break mixing function-style and c-style casts, and is
breaking bootstrapping llvm.
This reverts r230261.
llvm-svn: 230274
|
|
|
|
|
|
|
|
| |
the presence of an abstract declarator with a ptr-operator as proof that a
construct cannot parse as an expression to improve diagnostics along error
recovery paths.
llvm-svn: 230261
|
|
|
|
| |
llvm-svn: 229294
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first part of that line doesn't parse correctly and ParseClassSpecifier() for
some reason skips to tok::comma to recover, and then
ParseDeclarationSpecifiers() sees the next struct and calls
ParseClassSpecifier() again with the same DeclSpec object.
However, the first call already called ActOnCXXGlobalScopeSpecifier() on the
DeclSpec's CXXScopeSpec, and sema gets confused when this gets called again.
As a fix, let ParseClassSpecifier() (and ParseEnumSpecifier()) call
ParseOptionalCXXScopeSpec() with a temporary CXXScopeSpec object, and only
copy it into the DeclSpec if things work out. (This is also how all the other
functions that set the DeclSpec's TypeSpecScope set it.)
Found by SLi's bot.
llvm-svn: 229293
|
|
|
|
| |
llvm-svn: 229289
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first part of that line doesn't parse correctly and ParseClassSpecifier() for
some reason skips to tok::comma to recover, and then
ParseDeclarationSpecifiers() sees the next struct and calls
ParseClassSpecifier() again with the same DeclSpec object.
However, the first call already called ActOnCXXGlobalScopeSpecifier() on the
DeclSpec's CXXScopeSpec, and sema gets confused when this gets called again.
As a fix, let ParseClassSpecifier() (and ParseEnumSpecifier()) call
ParseOptionalCXXScopeSpec() with a temporary CXXScopeSpec object, and only
copy it into the DeclSpec if things work out. (This is also how all the other
functions that set the DeclSpec's TypeSpecScope set it.)
Found by SLi's bot.
llvm-svn: 229288
|
|
|
|
|
|
|
|
|
| |
Previously if an enumeration was used in a nested name specifier in pre-C++11
language dialect, error message was 'XXX is not a class, namespace, or scoped
enumeration'. This patch removes the word 'scoped' as in C++11 any enumeration
may be used in this context.
llvm-svn: 226410
|
|
|
|
|
|
|
|
|
|
| |
Parse of nested name spacifier is modified so that it properly recovers
if colon is mistyped as double colon in case statement.
This patch fixes PR15133.
Differential Revision: http://llvm-reviews.chandlerc.com/D2870
llvm-svn: 206135
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We would skip until the next comma, hoping good things whould lie there,
however this would fail when we have such things as this:
struct A {};
template <typename>
struct D;
template <>
struct D<C> : B, A::D;
Once this happens, we would believe that D with a nested namespace
specifier of A was a variable that was being declared. We would go on
to complain that there was an extraneous 'template <>' on their variable
declaration.
Crashes would happen when 'A' gets defined as 'enum class A {}' as
various asserts would fire.
Instead, we should skip up until the semicolon if we see that we are in
the middle of a definition and the current token is a ':'
This fixes PR17084.
llvm-svn: 196453
|
|
|
|
|
|
|
| |
case where the type in the following declaration is specified as a template-id,
and refactor for clarity.
llvm-svn: 195280
|
|
|
|
|
|
|
|
| |
and we see an ill-formed declarator that would probably be well-formed if the
tag definition were just missing a semicolon, use that as the diagnostic
instead of producing some other mysterious error.
llvm-svn: 195163
|
|
|
|
| |
llvm-svn: 194872
|
|
|
|
|
|
|
| |
definition. If we see something that looks like a namespace definition inside a
class, that strongly indicates that a close brace was missing somewhere.
llvm-svn: 194319
|
|
|
|
|
|
|
| |
preparation for teaching this function how to diagnose a correction that
includes importing a module.
llvm-svn: 188602
|
|
|
|
|
|
|
| |
Our error recovery path may have made the class anonymous, and that has a pretty
disastrous impact on any attempt to parse a class body containing constructors.
llvm-svn: 169374
|
|
|
|
|
|
| |
(so that it can have additional options set when trying to debug issues causing regressions).
llvm-svn: 166681
|
|
|
|
|
|
| |
this, for better error recovery.
llvm-svn: 166645
|
|
|
|
| |
llvm-svn: 158573
|
|
right place to pick up parsing. In C++, this had a tendency to skip everything
declared within headers if the TU starts with garbage.
llvm-svn: 154530
|