Age | Commit message (Collapse) | Author |
|
conflicts from a separate problematic patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158750 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The original r158700 caused crashes in the gcc test suite,
g++.abi/vtable3a.C among others. It also caused failures in the libc++
test suite.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158749 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
includes support for the align (which fixes PR12631).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158717 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Note that this is mostly a structural patch that handles the change from the old
spelling style to the new one. One consequence of this is that all AT_foo_bar
enum values have changed to not be based off of the first spelling, but rather
off of the class name, so they are now AT_FooBar and the like (a straw poll on
IRC showed support for this). Apologies for code churn.
Most attributes have GNU spellings as a temporary solution until everything else
is sorted out (such as a Keyword spelling, which I intend to add if someone else
doesn't beat me to it). This is definitely a WIP.
I've also killed BaseCheckAttr since it was unused, and I had to go through
every attribute anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158700 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Now, as long as the 'Namespaces' variable is correct inside Attr.td, the
generated code will correctly admit a C++11 attribute only when it has the
appropriate namespace(s).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158661 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
__forceinline is a combination of the inline keyword and __attribute__((always_inline))
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158653 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158573 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
all. Suppresses follow-on errors mentioned in PR13074.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158348 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
on the RecordDecl. Persist the MS portability type attributes and
ignore them in Sema rather than the parser.
Patch by João Matos!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157288 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156987 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
location
of the DeclStmt node, otherwise libclang will not work for anything inside that
class.
rdar://10837710
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156966 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156934 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156860 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and the thing we have has a scope specifier, and we're in a context that doesn't
allow declaring a qualified name, then the error is a malformed type, not a
missing type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156856 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
disambiguate whether the type name was forgotten or mistyped.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156854 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
parser, and use it to emit better diagnostics in cases where an identifer
can't be looked up as a type name.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156508 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
normal parse for token sequences like 'vector pixel foo'. This incidentally also
fixes a couple of wrong-parse issues.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156503 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
so that we actually accumulate all the delayed diagnostics. Do
this so that we can restore those diagnostics to good standing
if it turns out that we were wrong to suppress, e.g. if the
tag specifier is actually an elaborated type specifier and not
a declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156291 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
separate pools owned by the RAII objects that keep pushing
decl state. This gives us quite a bit more flexibility.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156289 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
refactorings in that revision, and some of the subsequent bugfixes, which
seem to be relevant even without delayed exception specification parsing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156031 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the parsing of such things appears to be a conforming extension, but it breaks
libstdc++4.7's std::pair.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155975 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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 :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155759 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155723 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to a given type, when the reason is that there is a non-type decl with
the same name.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155677 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
class; we would never actually parse it and attach it to the type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155426 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154844 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154799 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154746 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154723 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
right place to pick up parsing. In C++, this had a tendency to skip everything
declared within headers if the TU starts with garbage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154530 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154476 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154399 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
* 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154381 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
* 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 '[]'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154369 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154173 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153999 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
diagnostic and a fix-it to explain to the user where the ellipsis is
supposed to go.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153622 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
necessarily mean we've found a function declarator. If the next token is not
a ')', this is actually a parenthesized pack expansion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153544 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
isConstructorDeclaration also needs updating for any extension to the
grammar of a direct-declarator.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153490 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153488 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
class template's definition, and for explicit specializations of such enum
members.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153304 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153026 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
getDeclSpecContextFromDeclaratorContext.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152766 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152721 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
being defined here: [] () -> struct S {} does not define struct S.
In passing, implement DR1318 (syntactic disambiguation of 'final').
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152551 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152549 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152536 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152531 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and lots of tidying up.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152392 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
paren/brace/bracket tracking (the Consume* functions already did it),
removing the use of ConsumeAnyToken(), and moving the hot paths inline
with the error paths out-of-line.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152274 91177308-0d34-0410-b5e6-96231b3b80d8
|