Instead of bailing out of parsing when we encounter an invalid
template-name or template arguments in a template-id, produce an
annotation token describing the invalid construct.
This avoids duplicate errors and generally allows us to recover better.
In principle we should be able to extend this to store some kinds of
invalid template-id in the AST for tooling use, but that isn't handled
as part of this change.
Previously, if a semi-colon is unexpectedly added before a closing ')', ']' or
'}', two errors and one note would emitted, and the parsing would get confused
to which scope it was in. This change consumes the semi-colon, recovers
parsing better, and emits only one error with a fix-it.
llvm-svn: 237192
This used to crash, complaining "ObjectType and scope specifier cannot coexist":
struct A { } b = b.~A::A <int>;
The only other caller of ParseOptionalCXXScopeSpecifier() that passes in a
non-empty ObjectType clears the ObjectType of the scope specifier comes back
non-empty (see the tok::period case in Parser::ParsePostfixExpressionSuffix()),
so do that here too.
Found by SLi's bot.
llvm-svn: 227781
Even with r227555, this still crashed:
struct S {
int A;
~A::A() {}
};
That's because ParseOptionalCXXScopeSpecifier()'s call to
ActOnCXXNestedNameSpecifier() doesn't mark the scope spec as invalid if sema
thought it's a good idea to fixit-correct "::" to ":". For the diagnostic
improvement done in r217302, we never want :: to be interpreted as :, so fix
this by setting ColonSacred to false temporarily.
Found by SLi's bot.
llvm-svn: 227581
scope to -Wc++11-extensions. Move extra semicolon after member function
definition diagnostic out of -pedantic, since C++ allows a single semicolon
there. Keep it in -Wextra-semi, though, since it's still questionable.
llvm-svn: 160618
a warning for an extra semi-colon after function definitions. Added logic
so that a block of semi-colons on a line will only get one warning instead
of a warning for each semi-colon.
llvm-svn: 156934
constructor, but X is not a known typename, check whether the tokens could
possibly match the syntax of a declarator before concluding that it isn't
a constructor. If it's definitely ill-formed, assume it is a constructor.
Empirical evidence suggests that this pattern is much more often a
constructor with a typoed (or not-yet-declared) type name than any of the
other possibilities, so the extra cost of the check is not expected to be
problematic.
llvm-svn: 153488
function body. This keeps the brace count accurate to prevent
additional errors. Also, moved the caret from the brace to the function
name.
Code:
class F{ int Foo{ return 1; } };
Fixed error:
parameters.cc:1:14: error: function definition does not declare parameters
class F{ int Foo{ return 1; } };
^
1 error generated.
Old errors:
parameters.cc:1:17: error: function definition does not declare parameters
class F{ int Foo{ return 1; } };
^
parameters.cc:1:30: error: expected ';' after class
class F{ int Foo{ return 1; } };
^
;
parameters.cc:1:31: error: expected external declaration
class F{ int Foo{ return 1; } };
^
3 errors generated.
llvm-svn: 148621
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
redeclarations. For example, checks that a class template
redeclaration has the same template parameters as previous
declarations.
Detangled class-template checking from ActOnTag, whose logic was
getting rather convoluted because it tried to handle C, C++, and C++
template semantics in one shot.
Made some inroads toward eliminating extraneous "declaration does not
declare anything" errors by adding an "error" type specifier.
llvm-svn: 63973
C++ handle anonymous structs/unions in the same way. Addresses several
bugs:
<rdar://problem/6259534>
<rdar://problem/6481130>
<rdar://problem/6483159>
The test case in PR clang/1750 now passes with -fsyntax-only, but
CodeGen for inline assembler still fails.
llvm-svn: 62112
Note that Parser::ParseCXXMemberSpecification is temporarily disabled until the Sema support is in place.
Once ParseCXXMemberSpecification is enabled, the Parser/cxx-class.cpp test will pass.
llvm-svn: 52694