| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 155870
|
| |
|
|
|
|
|
| |
victim. Don't crash if we have a delay-parsed exception specification for a
class member which is invalid in a way which precludes building a FunctionDecl.
llvm-svn: 155788
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
t.c:3:9: error: expected expression
if (x)) {
^
.. which isn't even true - a statement or expression is fine. After:
t.c:3:9: error: extraneous ')' after condition, expected a statement
if (x)) {
^
This is the second part of PR12595
llvm-svn: 155762
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows
us to improve this diagnostic (telling us to insert another ")":
t.c:2:19: error: expected ';' at end of declaration
int x = 4+(5-12));
^
;
to:
t.c:2:19: error: extraneous ')' before ';'
int x = 4+(5-12));
^
...telling us to remove the ")". This is PR12595. There are more uses of ExpectAndConsumeSemi
that could be switched over, but I don't hit them on a daily basis :)
llvm-svn: 155759
|
| |
|
|
| |
llvm-svn: 155723
|
| |
|
|
|
|
|
| |
to a given type, when the reason is that there is a non-type decl with
the same name.
llvm-svn: 155677
|
| |
|
|
|
|
| |
Fixes PR12581.
llvm-svn: 155670
|
| |
|
|
| |
llvm-svn: 155596
|
| |
|
|
|
|
| |
class; we would never actually parse it and attach it to the type.
llvm-svn: 155426
|
| |
|
|
|
|
|
|
| |
uninitialized memory if the input wasn't 0-terminated.
Found by valgrind.
llvm-svn: 155323
|
| |
|
|
|
|
|
| |
exception specifications in C++11 until after we've parsed the exception
specifications for nested classes.
llvm-svn: 155293
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
followed by an identifier as declaration specificer (except for ObjC).
This allows e.g. an out-of-line C++ member function definitions to be
recognized as functions and not as variable declarations if the type
name for the first parameter is not recognized as a type--say, when there
is a function name shadowing an enum type name and the parameter is
missing the "enum" keyword needed to distinguish the two.
Note that returning TPResult::Error() instead of TPResult::True()
appears to have the same end result, while TPResult::Ambiguous()
results in a crash.
llvm-svn: 155163
|
| |
|
|
| |
llvm-svn: 155082
|
| |
|
|
|
|
|
|
|
| |
exception specifications on member functions until after the closing
'}' for the containing class. This allows, for example, a member
function to throw an instance of its own class. Fixes PR12564 and a
fairly embarassing oversight in our C++98/03 support.
llvm-svn: 154844
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in the declaration of a non-static member function after the
(optional) cv-qualifier-seq, which in practice means in the exception
specification and late-specified return type.
The new scheme here used to manage 'this' outside of a member function
scope is more general than the Scope-based mechanism previously used
for non-static data member initializers and late-parsesd attributes,
because it can also handle the cv-qualifiers on the member
function. Note, however, that a separate pass is required for static
member functions to determine whether 'this' was used, because we
might not know that we have a static function until after declaration
matching.
Finally, this introduces name mangling for 'this' and for the implicit
'this', which is intended to match GCC's mangling. Independent
verification for the new mangling test case would be appreciated.
Fixes PR10036 and PR12450.
llvm-svn: 154799
|
| |
|
|
| |
llvm-svn: 154746
|
| |
|
|
|
|
|
|
|
|
| |
Instead, make it the allocation function's responsibility to add them
to a list and clear it when a top-level decl is finished.
This plugs leakage of TemplateAnnotationIds. DelayedCleanupPool is
ugly and unused, remove it.
llvm-svn: 154743
|
| |
|
|
|
|
|
|
|
| |
attached. Since we do not support any attributes which appertain to a statement
(yet), testing of this is necessarily quite minimal.
Patch by Alexander Kornienko!
llvm-svn: 154723
|
| |
|
|
| |
llvm-svn: 154584
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 154476
|
| |
|
|
| |
llvm-svn: 154399
|
| |
|
|
|
|
|
|
|
|
| |
* Alternative tokens (such as 'compl') are treated as identifiers in
attribute names.
* An attribute-list can start with a comma.
* An ellipsis may not be used with either of our currently-supported
C++11 attributes.
llvm-svn: 154381
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* In C++11, '[[' is ill-formed unless it starts an attribute-specifier. Reject
array sizes and array indexes which begin with a lambda-expression. Recover by
parsing the lambda as a lambda.
* In Objective-C++11, either '[' could be the start of a message-send.
Fully disambiguate this case: it turns out that the grammars of message-sends,
lambdas and attributes do not actually overlap. Accept any occurrence of '[['
where either '[' starts a message send, but reject a lambda in an array index
just like in C++11 mode.
Implement a couple of changes to the attribute wording which occurred after our
attributes implementation landed:
* In a function-declaration, the attributes go after the exception specification,
not after the right paren.
* A reference type can have attributes applied.
* An 'identifier' in an attribute can also be a keyword. Support for alternative
tokens (iso646 keywords) in attributes to follow.
And some bug fixes:
* Parse attributes after declarator-ids, even if they are not simple identifiers.
* Do not accept attributes after a parenthesized declarator.
* Accept attributes after an array size in a new-type-id.
* Partially disamiguate 'delete' followed by a lambda. More work is required
here for the case where the lambda-introducer is '[]'.
llvm-svn: 154369
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, using a an integer outside [0, 1] as a boolean constant seems to
be an easy mistake to make with things like "x == a || b" where the author
intended "x == a || x == b".
The bug caused by calling SkipUntil with three token kinds was also identified
by a VC diagnostic & reported by Francois Pichet as review feedback for my
commit r154163. I've included test cases to verify the error recovery that was
broken/poorly implemented due to this bug.
The other fix (lib/Sema/SemaExpr.cpp) seems like that code was never actually
reached in any of Clang's tests & is related to Objective C features I'm not
familiar with, so I've not been able to construct a test case for it. Perhaps
someone else can.
llvm-svn: 154325
|
| |
|
|
|
|
|
|
|
|
|
| |
In a few cases clang emitted a rather content-free diagnostic: 'parse error'.
This change replaces two actual cases (template parameter parsing and K&R
parameter declaration parsing) with more specific diagnostics and removes a
third dead case of this in the BalancedDelimiterTracker (the ctor already
checked the invariant necessary to ensure that the diag::parse_error was never
actually used).
llvm-svn: 154224
|
| |
|
|
|
|
|
|
|
| |
root class is intentionally declared.
The warning this inhibits, -Wobjc-root-class, is opt-in for now. However, all clang unit tests that would trigger
the warning have been updated to use -Wno-objc-root-class. <rdar://problem/7446698>
llvm-svn: 154187
|
| |
|
|
| |
llvm-svn: 154173
|
| |
|
|
|
|
|
|
|
|
|
| |
Based on Doug's feedback to r153887 this omits the FixIt if the following token
isn't syntactically valid for the context. (not a comma, '...', identifier,
'>', or '>>')
There's a bunch of work to handle the '>>' case, but it makes for a much more
pleasant diagnostic in this case.
llvm-svn: 154163
|
| |
|
|
|
|
|
|
| |
parameter.
Change suggested by Sebastian Redl on review feedback from r153887.
llvm-svn: 154102
|
| |
|
|
|
|
|
|
|
|
| |
a type specifier and can be combined with unsigned. This allows libstdc++4.7 to
be used with clang in c++98 mode.
Several other changes are still required for libstdc++4.7 to work with clang in
c++11 mode.
llvm-svn: 153999
|
| |
|
|
|
|
|
| |
statement-expressions. Prevents cleanups and such from being
claimed by the first full-expression in the block.
llvm-svn: 153989
|
| |
|
|
| |
llvm-svn: 153895
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The diagnostic message correctly informs the user that they have omitted the
'class' keyword, but neither suggests this insertion as a fixit, nor attempts
to recover as if they had provided the keyword.
This fixes the recovery, adds the fixit, and adds a separate diagnostic and
corresponding replacement fixit for cases where the user wrote 'struct' or
'typename' instead of 'class' (suggested by Richard Smith as a possible common
mistake).
I'm not sure the diagnostic message for either the original or new cases feel
very Clang-esque, so I'm open to suggestions there. The fixit hints make it
fairly easy to see what's required, though.
llvm-svn: 153887
|
| |
|
|
|
|
|
| |
diagnostic and a fix-it to explain to the user where the ellipsis is
supposed to go.
llvm-svn: 153622
|
| |
|
|
|
|
|
| |
necessarily mean we've found a function declarator. If the next token is not
a ')', this is actually a parenthesized pack expansion.
llvm-svn: 153544
|
| |
|
|
|
|
|
| |
isConstructorDeclaration also needs updating for any extension to the
grammar of a direct-declarator.
llvm-svn: 153490
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
recover by returning the statements that we parsed so far, instead of
dropping the whole function body.
rdar://10967343
llvm-svn: 153367
|
| |
|
|
|
|
|
| |
class template's definition, and for explicit specializations of such enum
members.
llvm-svn: 153304
|
| |
|
|
| |
llvm-svn: 153129
|
| |
|
|
|
|
| |
arguments.
llvm-svn: 153026
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enable incremental parsing by the Preprocessor,
where more code can be provided after an EOF.
It mainly prevents the tearing down of the topmost lexer.
To be used like this:
PP.enableIncrementalProcessing();
while (getMoreSource()) {
while (Parser.ParseTopLevelDecl(ADecl)) {...}
}
PP.enableIncrementalProcessing(false);
llvm-svn: 152914
|
| |
|
|
|
|
| |
getDeclSpecContextFromDeclaratorContext.
llvm-svn: 152766
|
| |
|
|
| |
llvm-svn: 152721
|
| |
|
|
| |
llvm-svn: 152559
|
| |
|
|
|
|
|
|
| |
being defined here: [] () -> struct S {} does not define struct S.
In passing, implement DR1318 (syntactic disambiguation of 'final').
llvm-svn: 152551
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
defined here, but not semantically, so
new struct S {};
is always ill-formed, even if there is a struct S in scope.
We also had a couple of bugs in ParseOptionalTypeSpecifier caused by it being
under-loved (due to it only being used in a few places) so merge it into
ParseDeclarationSpecifiers with a new DeclSpecContext. To avoid regressing, this
required improving ParseDeclarationSpecifiers' diagnostics in some cases. This
also required teaching ParseSpecifierQualifierList about constexpr... which
incidentally fixes an issue where we'd allow the constexpr specifier in other
bad places.
llvm-svn: 152549
|
| |
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
| |
|
|
| |
llvm-svn: 152531
|