Objective-C type arguments can be provided in angle brackets following
an Objective-C interface type. Syntactically, this is the same
position as one would provide protocol qualifiers (e.g.,
id<NSCopying>), so parse both together and let Sema sort out the
ambiguous cases. This applies both when parsing types and when parsing
the superclass of an Objective-C class, which can now be a specialized
type (e.g., NSMutableArray<T> inherits from NSArray<T>).
Check Objective-C type arguments against the type parameters of the
corresponding class. Verify the length of the type argument list and
that each type argument satisfies the corresponding bound.
Specializations of parameterized Objective-C classes are represented
in the type system as distinct types. Both specialized types (e.g.,
NSArray<NSString *> *) and unspecialized types (NSArray *) are
represented, separately.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241542 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This change adds parsing for the concept keyword in a
declaration and tracks the location. Diagnostic testing added for
invalid use of concept keyword.
Reviewers: faisalv, fraggamuffin, rsmith, hubert.reinterpretcast
Reviewed By: rsmith, hubert.reinterpretcast
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10528
Patch by Nathan Wilson!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241060 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements the functionality specified by DR948.
The changes are two fold. First, the parser was modified
to allow 'constexpr's to appear in condition declarations
(which was a hard error before). Second, Sema was modified
to cleanup maybe odr-used declarations by way of a call to
'ActOnFinishFullExpr'. As 'constexpr's were not allowed in
condition declarations before the cleanup wasn't necessary
(such declarations were always odr-used).
This fixes PR22491.
Differential Revision: http://reviews.llvm.org/D8978
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240707 91177308-0d34-0410-b5e6-96231b3b80d8
Addresses a conflict with glibc's __nonnull macro by renaming the type
nullability qualifiers as follows:
__nonnull -> _Nonnull
__nullable -> _Nullable
__null_unspecified -> _Null_unspecified
This is the major part of rdar://problem/21530726, but does not yet
provide the Darwin-specific behavior for the old names.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240596 91177308-0d34-0410-b5e6-96231b3b80d8
...instead of as a special case in ParseObjCTypeName with lots of
duplicated logic. Besides being a nice refactoring, this also allows
"- (instancetype __nonnull)self" in addition to "- (nonnull instancetype)self".
rdar://problem/19924646
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240188 91177308-0d34-0410-b5e6-96231b3b80d8
Introduces the type specifiers __nonnull, __nullable, and
__null_unspecified that describe the nullability of the pointer type
to which the specifier appertains. Nullability type specifiers improve
on the existing nonnull attributes in a few ways:
- They apply to types, so one can represent a pointer to a non-null
pointer, use them in function pointer types, etc.
- As type specifiers, they are syntactically more lightweight than
__attribute__s or [[attribute]]s.
- They can express both the notion of 'should never be null' and
also 'it makes sense for this to be null', and therefore can more
easily catch errors of omission where one forgot to annotate the
nullability of a particular pointer (this will come in a subsequent
patch).
Nullability type specifiers are maintained as type sugar, and
therefore have no effect on mangling, encoding, overloading,
etc. Nonetheless, they will be used for warnings about, e.g., passing
'null' to a method that does not accept it.
This is the C/C++ part of rdar://problem/18868820.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240146 91177308-0d34-0410-b5e6-96231b3b80d8
Note: __declspec is also temporarily enabled when compiling for a CUDA target because there are implementation details relying on __declspec(property) support currently. When those details change, __declspec should be disabled for CUDA targets.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238238 91177308-0d34-0410-b5e6-96231b3b80d8
__declspec(align(...)) is unlike all other attributes in that it is not
applied to a variable if it appears before the class-key. If the
tag in question isn't part of a variable declaration, it is not ignored.
Instead, the alignment attribute is applied to the tag.
This fixes PR18024.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235272 91177308-0d34-0410-b5e6-96231b3b80d8
Sema overrides ASTContext's policy on the first emitted diagnostic
(doesn't matter if it's ignored or not). This means changing the order
of diagnostic emission in Sema suddenly changes the text of diagnostic
emitted from the parser.
In the test case -Wmissing-prototypes (ignored) was the culprit, use
'int main' to suppress that warning so we see when this regresses.
Also move it into Sema/ as it's not testing any C++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232039 91177308-0d34-0410-b5e6-96231b3b80d8
The first part of that line doesn't parse correctly and ParseClassSpecifier() for
some reason skips to tok::comma to recover, and then
ParseDeclarationSpecifiers() sees the next struct and calls
ParseClassSpecifier() again with the same DeclSpec object.
However, the first call already called ActOnCXXGlobalScopeSpecifier() on the
DeclSpec's CXXScopeSpec, and sema gets confused when this gets called again.
As a fix, let ParseClassSpecifier() (and ParseEnumSpecifier()) call
ParseOptionalCXXScopeSpec() with a temporary CXXScopeSpec object, and only
copy it into the DeclSpec if things work out. (This is also how all the other
functions that set the DeclSpec's TypeSpecScope set it.)
Found by SLi's bot.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229288 91177308-0d34-0410-b5e6-96231b3b80d8
The improved completion in call context now works with:
- Functions.
- Member functions.
- Constructors.
- New expressions.
- Function call expressions.
- Template variants of the previous.
There are still rough edges to be fixed:
- Provide support for optional parameters. (fix known)
- Provide support for member initializers. (fix known)
- Provide support for variadic template functions. (fix unknown)
- Others?
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226670 91177308-0d34-0410-b5e6-96231b3b80d8
The EOF token injection technique is preferable to using
isBeforeInTranslationUnit to determine whether or not additional cleanup
is needed. I don't have an example off-hand that requires it but it is
nicer nonetheless.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225776 91177308-0d34-0410-b5e6-96231b3b80d8
I added setEofData/getEofData to solve this sort of problem back in
r224505. Use the Param's decl to tell us if this is *our* EOF token.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225619 91177308-0d34-0410-b5e6-96231b3b80d8
Weird constructs like __attribute__((inline)) or
__attibute__((typename)) should result in warnings, not errors.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225118 91177308-0d34-0410-b5e6-96231b3b80d8
isDeclarationSpecifier performs error recovers which jostles the token
stream. Specifically, TryAnnotateTypeOrScopeToken will end up consuming
a typename token which will confuse the attribute parsing machinery as
we no-longer have something identifier-like.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224903 91177308-0d34-0410-b5e6-96231b3b80d8
The parser can only be tricked into parsing a function template
definition by inserting a typename keyword before the function template
declaration. This used to make us crash, and now it's fixed.
While here, remove an unneeded boolean parameter from ParseDeclGroup.
This boolean always corresponded to non-typedef declarators at file
scope. ParseDeclGroup already has precise diagnostics for the function
definition typedef case, so we can let that through.
Fixes PR21839.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224287 91177308-0d34-0410-b5e6-96231b3b80d8
should indicate a c++ parameter pack not a c-variadic.
int i = [](auto...) { return 0; }(); // OK now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223357 91177308-0d34-0410-b5e6-96231b3b80d8
To support it in the frontend, the following has been added:
- generic address space type attribute;
- documentation for the OpenCL address space attributes;
- parsing of __generic(generic) keyword;
- test code for the parser and diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222831 91177308-0d34-0410-b5e6-96231b3b80d8
std::X::swap exception specifications (allowing parsing of non-conforming code
in libstdc++). The old conditions also matched the functions in MSVC's STL,
which were relying on deferred parsing here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222471 91177308-0d34-0410-b5e6-96231b3b80d8
Sema::ActOnIdExpression to use the new functionality.
Among other things, this allows recovery in several cases where it
wasn't possible before (e.g. correcting a mistyped static_cast<>).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222464 91177308-0d34-0410-b5e6-96231b3b80d8
a member named 'swap' and then expect unqualified lookup for the name 'swap' in
its exception specification to find anything else.
Without delay-parsed exception specifications, this was ill-formed (NDR) by
[basic.scope.class]p1, rule 2. With delay-parsed exception specifications, the
call to 'swap' unambiguously finds the function being declared, which then
fails because the arguments don't work for that function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221955 91177308-0d34-0410-b5e6-96231b3b80d8
This is to accept "NA" in place of vesion number for availability
attribute. Used on introduced=NA to mean unavailable
and deprecated=NA to mean nothing (not deprecated).
rdar://18804883
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221417 91177308-0d34-0410-b5e6-96231b3b80d8
Wire it through everywhere we have support for fastcall, essentially.
This allows us to parse the MSVC "14" CTP headers, but we will
miscompile them because LLVM doesn't support __vectorcall yet.
Reviewed By: Aaron Ballman
Differential Revision: http://reviews.llvm.org/D5808
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220573 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor