Age | Commit message (Collapse) | Author |
|
conversion-type-id, in preparation for this becoming valid in c++1y mode.
No functionality change; small diagnostic improvement.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181089 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
are now two distinct canonical 'AutoType's: one is the undeduced 'auto'
placeholder type, and the other is a deduced-but-dependent type. All
deduced-to-a-non-dependent-type cases are still non-canonical.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180789 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180610 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
<type_traits>.
Patch by me and Ryan Molden.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178111 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
using-declarations with names which look constructor-like are interpreted as
constructor names.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177957 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Post-commit CR feedback from Jordan Rose regarding r175594.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175679 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
diagnose attributes on alias declarations, using directives, and attribute
declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175649 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This required plumbing through a new flag to determine whether a ParmVarDecl is
actually a parameter of a function declaration (as opposed to a function
typedef etc, where the attribute is prohibited). Weirdly, this attribute (just
like [[noreturn]]) cannot be applied to a function type, just to a function
declaration (and its parameters).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173726 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
brought into 'clang' namespace by clang/Basic/LLVM.h
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172323 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
nearby 'C++0x' comments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171372 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171367 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
which is wrong here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170721 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
single attribute in the future.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170500 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168855 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
')', if found. Don't crash.
Fixes PR11852.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167268 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
literal-operator-id.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166373 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165259 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
typeid (and a couple other non-standard places where we can transform an
unevaluated expression into an evaluated expression) is special
because it introduces an an expression evaluation context,
which conflicts with the mechanism to compute the current
lambda mangling context. PR12123.
I would appreciate if someone would double-check that we get the mangling
correct with this patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164658 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Andy Gibbs!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164591 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162506 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
MutableArrayRef.
This required changing all get() calls to data() and using the simpler constructors.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162501 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
SmallVector.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162492 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
These were nops for quite a while and only lead to confusion. ASTMultiPtr
now behaves like a proper dumb array reference.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162475 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162212 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
nested names as id-expressions, using the annot_primary_expr annotation, where
possible. This removes some redundant lookups, and also allows us to
typo-correct within tentative parsing, and to carry on disambiguating past an
identifier which we can determine will fail lookup as both a type and as a
non-type, allowing us to disambiguate more declarations (and thus offer
improved error recovery for such cases).
This also introduces to the parser the notion of a tentatively-declared name,
which is an identifier which we *might* have seen a declaration for in a
tentative parse (but only if we end up disambiguating the tokens as a
declaration). This is necessary to correctly disambiguate cases where a
variable is used within its own initializer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162159 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
standard reference and add a test.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161604 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
code-completion and an Objective-C message send, based on Jordan's
feedback.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161049 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
lambda-introducer in Objective-C++11, fall back to treating the tokens
as an Objective-C message send to provide those (more likely)
completions. Fixes <rdar://problem/11980263>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161015 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
accurate by asking the parser whether there was an ambiguity rather than trying
to reverse-engineer it from the DeclSpec. Make the with-parameters case have
better diagnostics by using semantic information to drive the warning,
improving the diagnostics and adding a fixit.
Patch by Nikola Smiljanic. Some minor changes by me to suppress diagnostics for
declarations of the form 'T (*x)(...)', which seem to have a very high false
positive rate, and to reduce indentation in 'warnAboutAmbiguousFunction'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160998 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
attributes in more places where we didn't and catching a lot more issues.
This implements nearly every aspect of C++11 attribute parsing, except for:
- Attributes are permitted on explicit instantiations inside the declarator
(but not preceding the decl-spec)
- Attributes are permitted on friend declarations of functions.
- Multiple instances of the same attribute in an attribute-list (e.g.
[[noreturn, noreturn]], not [[noreturn]] [[noreturn]] which is conforming)
are allowed.
The first two are marked as expected-FIXME in the test file and the latter
is probably a defect and is currently untested.
Thanks to Richard Smith for providing the lion's share of the testcases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159072 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
also deal with '>>>' (in CUDA), '>=', and '>>='. Fix the FixItHints logic to
deal with cases where the token is followed by an adjacent '=', '==', '>=',
'>>=', or '>>>' token, where a naive fix-it would result in a differing token
stream on a re-lex.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158652 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158572 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
|
|
where '>' is going to behave as an operator (and not as a '>' closing
a template argument list).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158111 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
|
|
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
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154743 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
|
|
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
|
|
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
|
|
for a few kinds of error. Specifically:
Since we're after translation phase 6, the "" token might be formed by multiple
source-level string literals. Checking the token width is not a correct way of
detecting empty string literals, due to escaped newlines. Diagnose and recover
from a missing space between "" and suffix, and from string literals other than
"", which are followed by a suffix.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152348 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152098 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that provides the behavior of the C++11 library trait
std::is_trivially_constructible<T, Args...>, which can't be
implemented purely as a library.
Since __is_trivially_constructible can have zero or more arguments, I
needed to add Yet Another Type Trait Expression Class, this one
handling arbitrary arguments. The next step will be to migrate
UnaryTypeTrait and BinaryTypeTrait over to this new, more general
TypeTrait class.
Fixes the Clang side of <rdar://problem/10895483> / PR12038.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151352 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
compiler support for the std::is_trivially_assignable library type
trait.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151240 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the diagnostic for using a parenthesized direct-initializer in a condition.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151137 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that 'this' can be used in the brace-or-equal-initializer of a
non-static data member, and C++11 [expr.prim.lambda]p9, which says
that lambda expressions not in block scope can have no captures, side
fully with C++11 [expr.prim.general]p4 by allowing 'this' to be
captured within these initializers. This seems to be the intent of
non-static data member initializers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151101 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
name mangling in the Itanium C++ ABI for lambda expressions is so
dependent on context, we encode the number used to encode each lambda
as part of the lambda closure type, and maintain this value within
Sema.
Note that there are a several pieces still missing:
- We still get the linkage of lambda expressions wrong
- We aren't properly numbering or mangling lambda expressions that
occur in default function arguments or in data member initializers.
- We aren't (de-)serializing the lambda numbering tables
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150982 91177308-0d34-0410-b5e6-96231b3b80d8
|