This change adds a new type node, DeducedTemplateSpecializationType, to
represent a type template name that has been used as a type. This is modeled
around AutoType, and shares a common base class for representing a deduced
placeholder type.
We allow deduced class template types in a few more places than the standard
does: in conditions and for-range-declarators, and in new-type-ids. This is
consistent with GCC and with discussion on the core reflector. This patch
does not yet support deduced class template types being named in typename
specifiers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293207 91177308-0d34-0410-b5e6-96231b3b80d8
Under this defect resolution, the injected-class-name of a class or class
template cannot be used except in very limited circumstances (when declaring a
constructor, in a nested-name-specifier, in a base-specifier, or in an
elaborated-type-specifier). This is apparently done to make parsing easier, but
it's a pain for us since we don't know whether a template-id using the
injected-class-name is valid at the point when we annotate it (we don't yet
know whether the template-id will become part of an elaborated-type-specifier).
As a tentative resolution to a perceived language defect, mem-initializer-ids
are added to the list of exceptions here (they generally follow the same rules
as base-specifiers).
When the reference to the injected-class-name uses the 'typename' or 'template'
keywords, we permit it to be used to name a type or template as an extension;
other compilers also accept some cases in this area. There are also a couple of
corner cases with dependent template names that we do not yet diagnose, but
which will also get this treatment.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292518 91177308-0d34-0410-b5e6-96231b3b80d8
We were previouly assuming that every type template was a class template, which
is not true any more.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291988 91177308-0d34-0410-b5e6-96231b3b80d8
Diasllow a declaration using the 'auto' type specifier from using two different
meanings of it at once, or from declaring multiple functions with deduced
return types or introducing multiple trailing return types.
The standard does not technically disallow the multiple trailing return types
case if all the declarators declare variables (such as function pointers with
trailing return types), but we disallow that too, following the clear intent.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291880 91177308-0d34-0410-b5e6-96231b3b80d8
This flag serves no purpose other than to prevent us walking through a type to
check whether it contains an 'auto' specifier; this duplication of information
is error-prone, does not appear to provide any performance benefit, and will
become less practical once we support C++1z deduced class template types and
eventually constrained types from the Concepts TS.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291737 91177308-0d34-0410-b5e6-96231b3b80d8
filter out the implicilty imported modules at CodeGen instead of removing the
implicit ImportDecl when an implementation TU of a module imports a header of
that same module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291688 91177308-0d34-0410-b5e6-96231b3b80d8
are building an implemenation of module X.
This fixes a regression caused by r280409.
rdar://problem/29930553
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291628 91177308-0d34-0410-b5e6-96231b3b80d8
Added a map to associate types and declarations with extensions.
Refactored existing diagnostic for disabled types associated with extensions and extended it to declarations for generic situation.
Fixed some bugs for types associated with extensions.
Allow users to use pragma to declare types and functions for supported extensions, e.g.
#pragma OPENCL EXTENSION the_new_extension_name : begin
// declare types and functions associated with the extension here
#pragma OPENCL EXTENSION the_new_extension_name : end
Differential Revision: https://reviews.llvm.org/D21698
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289979 91177308-0d34-0410-b5e6-96231b3b80d8
type differs from the type of the actual function due to having a different
exception specification.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289754 91177308-0d34-0410-b5e6-96231b3b80d8
r289225 broke AST invariants by reparenting enumerators into function
decl contexts. This improves things by only reparenting TagDecls while
also attempting to preserve the lexical declcontext chain. The
interesting example here is:
int f(struct S { enum E { a = 1 } b; } c);
The semantic contexts of E and S should be f, and the lexical context of
S should be f and the lexical context of E should be S. We didn't do
that with r289225, but now we should.
This change should also improve our behavior on this example:
void f() {
extern void ext(struct S { } o);
// S injected here
}
Before r289225 we would only remove 'S' from the surrounding tag
injection context if it was the TU, but now we properly reparent S from
f to ext.
Fixes PR31366
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289678 91177308-0d34-0410-b5e6-96231b3b80d8
Other compilers accept invalid code here that we reject, and we need a
better error message to try to convince users that the code is really
incorrect. Consider:
class Foo {
typedef MyIterHelper<Foo> iterator;
friend class iterator;
};
Previously our wording was "elaborated type refers to a typedef".
"elaborated type" isn't widely known terminology, so the new diagnostic
says "typedef 'iterator' cannot be referenced with class specifier".
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D25216
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289259 91177308-0d34-0410-b5e6-96231b3b80d8
This saves two pointers from FunctionDecl that were being used for some
rare and questionable C-only functionality. The DeclsInPrototypeScope
ArrayRef was added in r151712 in order to parse this kind of C code:
enum e {x, y};
int f(enum {y, x} n) {
return x; // should return 1, not 0
}
The challenge is that we parse 'int f(enum {y, x} n)' it its own
function prototype scope that gets popped before we build the
FunctionDecl for 'f'. The original change was doing two questionable
things:
1. Saving all tag decls introduced in prototype scope on a TU-global
Sema variable. This is problematic when you have cases like this, where
'x' and 'y' shouldn't be visible in 'f':
void f(void (*fp)(enum { x, y } e)) { /* no x */ }
This patch fixes that, so now 'f' can't see 'x', which is consistent
with GCC.
2. Storing the decls in FunctionDecl in ActOnFunctionDeclarator so that
they could be used in ActOnStartOfFunctionDef. This is just an
inefficient way to move information around. The AST lives forever, but
the list of non-parameter decls in prototype scope is short lived.
Moving these things to the Declarator solves both of these issues.
Reviewers: rsmith
Subscribers: jmolloy, cfe-commits
Differential Revision: https://reviews.llvm.org/D27279
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289225 91177308-0d34-0410-b5e6-96231b3b80d8
Some functions and templates are treated as __host__ __device__ even
when they don't have explicitly specified target attributes.
What's worse, this treatment may change depending on command line
options (-fno-cuda-host-device-constexpr) or
#pragma clang force_cuda_host_device.
Combined with strict checking for matching function target that comes
with D25809(r288962), it makes it hard to write code which would
explicitly instantiate or specialize some functions regardless of
pragmas or command line options in effect.
This patch changes the way we match target attributes of base template
vs attributes used in explicit instantiation or specialization so that
only explicitly specified attributes are considered. This makes base
template selection behave consistently regardless of pragma of command
line options that may affect CUDA target.
Differential Revision: https://reviews.llvm.org/D25845
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289091 91177308-0d34-0410-b5e6-96231b3b80d8
* __host__ __device__ functions are no longer considered to be
redeclarations of __host__ or __device__ functions. This prevents
unintentional merging of target attributes across them.
* Function target attributes are not considered (and must match) during
explicit instantiation and specialization of function templates.
Differential Revision: https://reviews.llvm.org/D25809
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288962 91177308-0d34-0410-b5e6-96231b3b80d8
This commit fixes PR20796. It implements the C only -Wstrict-prototypes warning.
Clang now emits a warning for function declarations which have no parameters
specified and for K&R function definitions with more than 0 parameters that are
not preceded by a previous prototype declaration.
The patch was originally submitted by Paul Titei!
rdar://15060615
Differential Revision: https://reviews.llvm.org/D16533
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288896 91177308-0d34-0410-b5e6-96231b3b80d8
import can't appear here" diagnostic if an already-visible module is textually
entered (because we have the module map but not the AST file) within a
function/namespace scope.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288737 91177308-0d34-0410-b5e6-96231b3b80d8
specifications in this mode in C++17, since they're part of the function type,
so check and diagnose them like we would if exceptions were enabled.
Better ideas welcome.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288220 91177308-0d34-0410-b5e6-96231b3b80d8
If initializer contains parentheses around braced list where it is not allowed,
as in construct int({0}), clang issued message like `functional-style cast
from 'void' to 'int' is not allowed`, which does not help much. Both gcc and
msvc issue message `list-initializer for non-class type must not be
parenthesized`, which is more descriptive. This change implements similar
message for clang.
Differential Revision: https://reviews.llvm.org/D25816
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286721 91177308-0d34-0410-b5e6-96231b3b80d8
In r286630, Decl::setInvalidDecl will automatically set the invalid flag for
BindingDecl for children in invalid DecompositionDecl. It no longer is
necessary to do a separate setInvalidDecl when finalizing a BindingDecl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286641 91177308-0d34-0410-b5e6-96231b3b80d8
aren't captured by lambdas with a default capture specifier
This commit is a follow-up to r286354. It avoids the -Wshadow warning for
variables which shadow variables that aren't captured by lambdas with a default
capture specifier. It provides an additional note that points to location of
the capture.
The old behaviour is preserved with -Wshadow-all or -Wshadow-uncaptured-local.
rdar://14984176
Differential Revision: https://reviews.llvm.org/D26448
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286465 91177308-0d34-0410-b5e6-96231b3b80d8
by lambdas with an explicit capture list
This commit avoids the -Wshadow warning for variables which shadow variables
that aren't captured by lambdas with an explicit capture list. It provides an
additional note that points to location of the explicit capture.
The old behaviour is preserved with -Wshadow-all or -Wshadow-uncaptured-local.
rdar://17135966
Differential Revision: https://reviews.llvm.org/D26278
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286354 91177308-0d34-0410-b5e6-96231b3b80d8
This commit improves the "must have C++ linkage" error diagnostics that are
emitted for C++ declarations like templates and literal operators by adding an
additional note that points to the appropriate extern "C" linkage specifier.
rdar://19021120
Differential Revision: https://reviews.llvm.org/D26189
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285823 91177308-0d34-0410-b5e6-96231b3b80d8
redeclaration in C++1z mode. We need the exception specification in order for
the function's type to be complete.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285779 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In CUDA compilation, we call isInlineDefinitionExternallyVisible (via
getGVALinkageForFunction) on functions while parsing their definitions.
At the point in time when we call getGVALinkageForFunction, we haven't
yet added the body to the function, so we trip this assert. But as far
as I can tell, this is harmless.
To work around this, we add a new flag to FunctionDecl, "WillHaveBody".
There was other code that was working around the existing assert with a
really awful hack -- this change lets us get rid of that hack.
Reviewers: rsmith, tra
Subscribers: aemerson, cfe-commits
Differential Revision: https://reviews.llvm.org/D25640
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285410 91177308-0d34-0410-b5e6-96231b3b80d8
OpenCL disallows using variadic arguments (s6.9.e and s6.12.5 OpenCL v2.0)
apart from some exceptions:
- printf
- enqueue_kernel
This change adds error diagnostic for variadic functions but accepts printf
and any compiler internal function (which should cover __enqueue_kernel_XXX cases).
It also unifies diagnostic with block prototype and adds missing uncaught cases for blocks.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285395 91177308-0d34-0410-b5e6-96231b3b80d8
similarly to scalar variables.
This commit makes the -Wunused-variable warning behaviour more consistent:
Now clang won't warn for array variables where it doesn't warn for scalar
variables.
rdar://24158862
Differential Revision: https://reviews.llvm.org/D25937
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285289 91177308-0d34-0410-b5e6-96231b3b80d8
Sema::ActOnTag creates TagDecls for records. However, if those record
declarations are invalid, and the parser is in C++ mode, it would
silently drop the TagDecl (and leave it as "beingDefined"). The problem
is that other code (e.g. the ASTWriter) will serialize all types, and
expects them to be complete. So, leaving them open would result in
failing asserts.
Fixes PR20320
Differential Revision: http://reviews.llvm.org/D21176
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285275 91177308-0d34-0410-b5e6-96231b3b80d8
This has the following ABI impact:
1) Functions whose parameter or return types are non-throwing function pointer
types have different manglings in c++1z mode from prior modes. This is
necessary because c++1z permits overloading on the noexceptness of function
pointer parameter types. A warning is issued for cases that will change
manglings in c++1z mode.
2) Functions whose parameter or return types contain instantiation-dependent
exception specifications change manglings in all modes. This is necessary
to support overloading on / SFINAE in these exception specifications, which
a careful reading of the standard indicates has essentially always been
permitted.
Note that, in order to be affected by these changes, the code in question must
specify an exception specification on a function pointer/reference type that is
written syntactically within the declaration of another function. Such
declarations are very rare, and I have so far been unable to find any code
that would be affected by this. (Note that such things will probably become
more common in C++17, since it's a lot easier to get a noexcept function type
as a function parameter / return type there.)
This change does not affect the set of symbols produced by a build of clang,
libc++, or libc++abi.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285150 91177308-0d34-0410-b5e6-96231b3b80d8
The problem with the original commit was that some of Apple's headers depended
on an incorrect behaviour, this commit adds a temporary workaround until those
headers are fixed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285098 91177308-0d34-0410-b5e6-96231b3b80d8
we don't collapse that down to a single entry if it's not a redeclaration.
Instead, set the Redeclaration bit on the Declarator to indicate whether a
function is a redeclaration (which may not have been linked into the
redeclaration chain if it's a dependent context friend).
Fixes a rejects-valid; see testcase.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284802 91177308-0d34-0410-b5e6-96231b3b80d8
implements the bulk of the change (modifying the type system to include
exception specifications), but not all the details just yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284337 91177308-0d34-0410-b5e6-96231b3b80d8
1) Merge and demote variable definitions when we find a redefinition in
MergeVarDecls, not only when we find one in AddInitializerToDecl (we only reach
the second case if it's the addition of the initializer itself that converts an
existing declaration into a definition).
2) When rebuilding a redeclaration chain for a variable, if we merge two
definitions together, mark the definitions as merged so the retained definition
is made visible whenever the demoted definition would have been.
Original commit message (from r283882):
[modules] PR28752: Do not instantiate variable declarations which are not visible.
Original patch by Vassil Vassilev! Changes listed above are mine.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284284 91177308-0d34-0410-b5e6-96231b3b80d8
In r276159, we started to defer emitting initializers for VarDecls, but
forgot to add the initializers for non-C++ language.
rdar://28740482
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284142 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith