| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
|
|
|
| |
class template's definition, and for explicit specializations of such enum
members.
llvm-svn: 153304
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
grammar requires a string-literal and not a user-defined-string-literal. The
two constructs are still represented by the same TokenKind, in order to prevent
a combinatorial explosion of different kinds of token. A flag on Token tracks
whether a ud-suffix is present, in order to prevent clients from needing to look
at the token's spelling.
llvm-svn: 152098
|
|
|
|
|
|
|
| |
string literal, and adjust the diagnostic code to match. This also causes us
to escape any control characters in the message.
llvm-svn: 152069
|
|
|
|
|
|
|
| |
GNU attributes to a better extent, by allowing them in more
places on a declator.
llvm-svn: 151945
|
|
|
|
|
|
| |
decltype expression.
llvm-svn: 151515
|
|
|
|
|
|
| |
__keywords or none of them.
llvm-svn: 151401
|
|
|
|
| |
llvm-svn: 151377
|
|
|
|
|
|
|
|
| |
pack" to use the same handling that gcc does. Fixes <rdar://problem/10871094> and <rdar://problem/10893316>.
(Hopefully, common usage of these pragmas isn't irregular enough to break our current handling. Doug has ideas for a more crazy approach if necessary.)
llvm-svn: 151307
|
|
|
|
|
|
| |
direct member initializers.
llvm-svn: 151155
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function call (or a comma expression with a function call on its right-hand
side), possibly parenthesized, then the return type is not required to be
complete and a temporary is not bound. Other subexpressions inside a decltype
expression do not get this treatment.
This is implemented by deferring the relevant checks for all calls immediately
within a decltype expression, then, when the expression is fully-parsed,
checking the relevant constraints and stripping off any top-level temporary
binding.
Deferring the completion of the return type exposed a bug in overload
resolution where completion of the argument types was not attempted, which
is also fixed by this change.
llvm-svn: 151117
|
|
|
|
|
|
| |
initializers of data members (both static and non-static).
llvm-svn: 151017
|
|
|
|
|
|
| |
Signed off by Richard Smith.
llvm-svn: 150464
|
|
|
|
|
|
| |
process removed some naming ambiguities.
llvm-svn: 149870
|
|
|
|
|
|
|
| |
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
llvm-svn: 149799
|
|
|
|
|
|
|
|
| |
include.
Fix all the transitive include users.
llvm-svn: 149783
|
|
|
|
| |
llvm-svn: 149127
|
|
|
|
| |
llvm-svn: 149124
|
|
|
|
|
|
|
|
|
|
| |
This is the last piece of N3031 (decltype in weird places) - supporting
the use of decltype in a class ctor's member-initializer-list to
specify the base classes to initialize.
Reviewed by Richard Smith.
llvm-svn: 148789
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- If the declarator is at the start of a line, and the previous line contained
another declarator and ended with a comma, then that comma was probably a
typo for a semicolon:
int n = 0, m = 1, l = 2, // k = 5;
myImportantFunctionCall(); // oops!
- If removing the parentheses would correctly initialize the object, then
produce a note suggesting that fix.
- Otherwise, if there is a simple initializer we can suggest which performs
value-initialization, then provide a note suggesting a correction to that
initializer.
Sema::Declarator now tracks the location of the comma prior to the declarator in
the declaration, if there is one, to facilitate providing the note. The code to
determine an appropriate initializer from the -Wuninitialized warning has been
factored out to allow use in both that and -Wvexing-parse.
llvm-svn: 148072
|
|
|
|
|
|
|
|
| |
- reject definitions of enums within friend declarations
- require 'enum', not 'enum class', for non-declaring references to scoped
enumerations
llvm-svn: 147824
|
|
|
|
|
|
| |
intended to cover C++ class definitions.
llvm-svn: 147808
|
|
|
|
|
|
|
|
| |
so this patch is surprisingly small.
Also drop -Wc1x-extensions in favor of -Wc11-extensions. I don't think we need to keep this around for compatibility.
llvm-svn: 147221
|
|
|
|
| |
llvm-svn: 146138
|
|
|
|
| |
llvm-svn: 145785
|
|
|
|
|
|
|
|
|
|
|
|
| |
default", make a note of which is used when creating the
initial declaration. Previously, we would wait until later to handle
default/delete as a definition, but this is too late: when adding the
declaration, we already treated the declaration as "user-provided"
when in fact it was merely "user-declared".
Fixes PR10861 and PR10442, along with a bunch of FIXMEs.
llvm-svn: 144011
|
|
|
|
|
|
|
| |
entering the context of a nested-name-specifier. Fixes
<rdar://problem/10397846>.
llvm-svn: 143967
|
|
|
|
| |
llvm-svn: 142937
|
|
|
|
|
|
| |
Doug's feedback.
llvm-svn: 142935
|
|
|
|
| |
llvm-svn: 142929
|
|
|
|
|
|
| |
decltype-specification when specifying a base type.
llvm-svn: 142928
|
|
|
|
| |
llvm-svn: 142926
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
analysis to separate dependent names from non-dependent names. For
dependent names, we'll behave differently from Visual C++:
- For __if_exists/__if_not_exists at class scope, we'll just warn
and then ignore them.
- For __if_exists/__if_not_exists in statements, we'll treat the
inner statement as a compound statement, which we only instantiate
in templates where the dependent name (after instantiation)
exists. This behavior is different from VC++, but it's as close as
we can get without encroaching ridiculousness.
The latter part (dependent statements) is not yet implemented.
llvm-svn: 142864
|
|
|
|
|
|
| |
'char32_t', 'constexpr', 'decltype', 'noexcept', 'nullptr' and 'static_assert'.
llvm-svn: 142302
|
|
|
|
|
|
|
| |
in -fms-extensions mode, make sure we actually use that initializer
after having handled the declaration. Fixes PR11150.
llvm-svn: 142195
|
|
|
|
|
|
| |
access specifier. The testcase has been changed to catch this too.
llvm-svn: 142186
|
|
|
|
| |
llvm-svn: 142056
|
|
|
|
|
|
| |
class/struct definition.
llvm-svn: 142054
|
|
|
|
| |
llvm-svn: 142049
|
|
|
|
|
|
|
| |
'final', and don't accept (then silently discard) braced init lists in C++98
new-expressions.
llvm-svn: 142048
|
|
|
|
| |
llvm-svn: 141999
|
|
|
|
|
|
| |
attributes are found, propagate them to subsequent declarations.
llvm-svn: 141861
|
|
|
|
|
|
| |
colon after access specifiers in C++
llvm-svn: 141852
|
|
|
|
|
|
|
| |
delimiter pairs and detect when we exceed the implementation limit for
nesting depth, from Aaron Ballman!
llvm-svn: 141782
|