such guides below explicit ones, and ensure that references to the class's
template parameters are not treated as forwarding references.
We make a few tweaks to the wording in the current standard:
1) The constructor parameter list is copied faithfully to the deduction guide,
without losing default arguments or a varargs ellipsis (which the standard
wording loses by omission).
2) If the class template declares no constructors, we add a T() -> T<...> guide
(which will only ever work if T has default arguments for all non-pack
template parameters).
3) If the class template declares nothing that looks like a copy or move
constructor, we add a T(T<...>) -> T<...> guide.
#2 and #3 follow from the "pretend we had a class type with these constructors"
philosophy for deduction guides.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295007 91177308-0d34-0410-b5e6-96231b3b80d8
This reinstates r293455, reverted in r293455, with a fix for cv-qualifier
handling on dependent typename-specifiers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293544 91177308-0d34-0410-b5e6-96231b3b80d8
non-template function instantiated from a friend declaration in a class
template from TSK_ImplicitInstantiation to TSK_Undeclared.
It doesn't make sense for a non-template function to be flagged as being
instantiated from a template; that property really belongs to the entity
as a whole and not an individual declaration of it. There's some history
here:
* r137934 started marking these functions as instantiations in order to
work around an issue where we might instantiate a class template while
we're still parsing its member definitions, and would otherwise fail
to instantiate the friend definition
* r177003 fixed the same issue but for friend templates, but did so by
making the friends claim to be definitions even before we'd parsed
their actual bodies; this made the r137934 change redundant
* r293558 worked around a problem caused by the marking of a non-template
function as a template instantiation in r137934
This change reverts the code changes from r293358 and r137934 and retains
all the tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293367 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes a crash in modules where the template class decl becomes the most recent
decl in the redeclaration chain and forcing the template instantiator try to
instantiate the friend declaration, rather than the template definition.
In practice, A::list<int> produces a TemplateSpecializationType
A::__1::list<int, allocator<type-parameter-0-0> >' failing to replace to
subsitute the default argument to allocator<int>.
Kudos Richard Smith (D28399).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291753 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
`diagnose_if` can be used to have clang emit either warnings or errors
for function calls that meet user-specified conditions. For example:
```
constexpr int foo(int a)
__attribute__((diagnose_if(a > 10, "configurations with a > 10 are "
"expensive.", "warning")));
int f1 = foo(9);
int f2 = foo(10); // warning: configuration with a > 10 are expensive.
int f3 = foo(f2);
```
It currently only emits diagnostics in cases where the condition is
guaranteed to always be true. So, the following code will emit no
warnings:
```
constexpr int bar(int a) {
foo(a);
return 0;
}
constexpr int i = bar(10);
```
We hope to support optionally emitting diagnostics for cases like that
(and emitting runtime checks) in the future.
Release notes will appear shortly. :)
Differential Revision: https://reviews.llvm.org/D27424
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291418 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Replace some old code that probably pre-dated the change to delay
emission of dllexported code until after the closing brace of the
outermost record type. Only uninstantiated default argument expressions
need to be handled now. It is enough to instantiate default argument
expressions when instantiating dllexported default ctors. This also
fixes some double-diagnostic issues in this area.
Fixes PR31500
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28274
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291045 91177308-0d34-0410-b5e6-96231b3b80d8
to make reference to template parameters. This is only a partial
implementation; we retain the restriction that the argument must not be
type-dependent, since it's unclear how that would work given the existence of
other language rules requiring an exact type match in this context, even for
type-dependent cases (a question has been raised on the core reflector).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290647 91177308-0d34-0410-b5e6-96231b3b80d8
This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.
This is a re-commit of r290080 (reverted in r290092) with a fix for a
use-after-lifetime bug.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290203 91177308-0d34-0410-b5e6-96231b3b80d8
This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290080 91177308-0d34-0410-b5e6-96231b3b80d8
* a dependent non-type using-declaration within a function template can be
valid, as it can refer to an enumerator, so don't reject it in the template
definition
* we can partially substitute into a dependent using-declaration if it appears
within a (local class in a) generic lambda within a function template, which
means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290071 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
clang-tidy checks frequently use source ranges of functions.
The source range of constructors and destructors in template instantiations
is currently a single token.
The factory method for constructors and destructors does not allow the
end source location to be specified.
Set end location manually after creating instantiation.
Reviewers: aaron.ballman, rsmith, arphaman
Subscribers: arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D26849
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288025 91177308-0d34-0410-b5e6-96231b3b80d8
During template instantiation, we currently fall back to just calling
Sema::SubstExpr for enable_if attributes that aren't value-dependent or
type-dependent. Since Sema::SubstExpr strips off any implicit casts
we've added to an expression, it's possible that this behavior will
leave us with an enable_if condition that's just a DeclRefExpr.
Conditions like that deeply confuse Sema::CheckEnableIf.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@287187 91177308-0d34-0410-b5e6-96231b3b80d8
Only look for a variable's value in the constant expression evaluation activation frame, if the variable was indeed declared in that frame, otherwise it might be a constant expression and be usable within a nested local scope or emit an error.
void f(char c) {
struct X {
static constexpr char f() {
return c; // error gracefully here as opposed to crashing.
}
};
int I = X::f();
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286748 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
within the instantiation of that same specialization. This could previously
happen for eagerly-instantiated function templates, variable templates,
exception specifications, default arguments, and a handful of other cases.
We still have an issue here for default template arguments that recursively
make use of themselves and likewise for substitution into the type of a
non-type template parameter, but in those cases we're producing a different
entity each time, so they should instead be caught by the instantiation depth
limit. However, currently we will typically run out of stack before we reach
it. :(
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280190 91177308-0d34-0410-b5e6-96231b3b80d8
to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly
determine whether a function definition is visible, and mark both the function
and the template as visible when merging function template definitions to
provide hasVisibleDefinition with the relevant information.
The change to always pass the right declaration as the PatternDef to
DiagnoseUninstantiableTemplate also caused those checks to happen before other
diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the
same situations, so I sunk the relevant diagnostics into
DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes
in reviews.llvm.org/D23492 by Vassil Vassilev.
This reinstates r279486, reverted in r279500, with a fix to
DiagnoseUninstantiableTemplate to only mark uninstantiable explicit
instantiation declarations as invalid if we actually diagnosed them. (When we
trigger an explicit instantiation of a class member from an explicit
instantiation declaration for the class, it's OK if there is no corresponding
definition and we certainly don't want to mark the member invalid in that
case.) This previously caused a build failure during bootstrap.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279557 91177308-0d34-0410-b5e6-96231b3b80d8
to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly
determine whether a function definition is visible, and mark both the function
and the template as visible when merging function template definitions to
provide hasVisibleDefinition with the relevant information.
The change to always pass the right declaration as the PatternDef to
DiagnoseUninstantiableTemplate also caused those checks to happen before other
diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the
same situations, so I sunk the relevant diagnostics into
DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes
in reviews.llvm.org/D23492 by Vassil Vassilev.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279486 91177308-0d34-0410-b5e6-96231b3b80d8
decomposition declarations.
There are a couple of things in the wording that seem strange here:
decomposition declarations are permitted at namespace scope (which we partially
support here) and they are permitted as the declaration in a template (which we
reject).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276492 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Space for storing the //constraint-expression// of the
//requires-clause// associated with a `TemplateParameterList` is
arranged by taking a bit out of the `NumParams` field for the purpose
of determining whether there is a //requires-clause// or not, and by
adding to the trailing objects tied to the `TemplateParameterList`. An
accessor is provided.
An appropriate argument is supplied to `TemplateParameterList::Create`
at the various call sites.
Serialization changes will addressed as the Concepts implementation
becomes more solid.
Drive-by fix:
This change also replaces the custom
`FixedSizeTemplateParameterListStorage` implementation with one that
follows the interface provided by `llvm::TrailingObjects`.
Reviewers: aaron.ballman, faisalv, rsmith
Subscribers: cfe-commits, nwilson
Differential Revision: https://reviews.llvm.org/D19322
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276069 91177308-0d34-0410-b5e6-96231b3b80d8
ArrayRef is a little better than passing around a pointer/length
pair.
No functional change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274732 91177308-0d34-0410-b5e6-96231b3b80d8
ArrayRef is a little better than passing around a pointer/length pair.
No functional change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274601 91177308-0d34-0410-b5e6-96231b3b80d8
ArrayRef is a little better than passing around a pointer/length pair.
No functional change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274475 91177308-0d34-0410-b5e6-96231b3b80d8
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274049 91177308-0d34-0410-b5e6-96231b3b80d8
variable weak discardable linkage and partially-ordered initialization, and is
implied for constexpr static data members.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273754 91177308-0d34-0410-b5e6-96231b3b80d8
pretty stack trace entries for all cases where we instantiate the definition of
something, and include the fully-qualified name with template arguments in the
name of the instantiated entity.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270904 91177308-0d34-0410-b5e6-96231b3b80d8
declared before it is used. Because we don't use normal name lookup to find
these, the normal code to filter out non-visible names from name lookup results
does not apply.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@268585 91177308-0d34-0410-b5e6-96231b3b80d8
with a generic lambda.
This patch fixes Sema::InstantiateVariableInitializer to switch to the
context of the variable before instantiating its initializer, which is
necessary to set the correct type for VarTemplateSpecializationDecl.
This is the first part of the patch that was reviewed here:
http://reviews.llvm.org/D19175
rdar://problem/23440346
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267956 91177308-0d34-0410-b5e6-96231b3b80d8
With this patch compiler emits warning if it tries to make implicit instantiation
of a template but cannot find the template definition. The warning can be suppressed
by explicit instantiation declaration or by command line options
-Wundefined-var-template and -Wundefined-func-template. The implementation follows
the discussion of http://reviews.llvm.org/D12326.
Differential Revision: http://reviews.llvm.org/D16396
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266719 91177308-0d34-0410-b5e6-96231b3b80d8
The linear clause declares one or more list items to be private to a SIMD lane and to have a linear relationship with respect to the iteration space of a loop.
'linear' '(' <linear-list> [ ':' <linear-step> ] ')'
When a linear-step expression is specified in a linear clause it must be
either a constant integer expression or an integer-typed parameter that is specified in a uniform clause on the directive.
The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266056 91177308-0d34-0410-b5e6-96231b3b80d8
The aligned clause declares that the object to which each list item points is aligned to the number of bytes expressed in the optional parameter of the aligned clause.
'aligned' '(' <argument-list> [ ':' <alignment> ] ')'
The optional parameter of the aligned clause, alignment, must be a constant positive integer expression. If no optional parameter is specified, implementation-defined default alignments for SIMD instructions on the target platforms are assumed.
The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266052 91177308-0d34-0410-b5e6-96231b3b80d8
OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive:
'uniform' '(' <argument-list> ')'
The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop.
The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266041 91177308-0d34-0410-b5e6-96231b3b80d8
construct.
OpenMP 4.0 defines '#pragma omp declare simd' construct that may have
associated 'simdlen' clause with constant positive expression as an
argument:
simdlen(<const_expr>)
Patch adds parsin and semantic analysis for simdlen clause.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265668 91177308-0d34-0410-b5e6-96231b3b80d8
Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct.
User-defined reductions are defined as
#pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )]
These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The
combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will
denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting
combined value after executing the combiner.
As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause
will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier
omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced.
Differential Revision: http://reviews.llvm.org/D11182
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262582 91177308-0d34-0410-b5e6-96231b3b80d8
This is like r262493, but for pragma detect_mismatch instead of pragma comment.
The two pragmas have similar behavior, so use the same approach for both.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262506 91177308-0d34-0410-b5e6-96231b3b80d8
`#pragma comment` was handled by Sema calling a function on ASTConsumer, and
CodeGen then implementing this function and writing things to its output.
Instead, introduce a PragmaCommentDecl AST node and hang one off the
TranslationUnitDecl for every `#pragma comment` line, and then use the regular
serialization machinery. (Since PragmaCommentDecl has codegen relevance, it's
eagerly deserialized.)
http://reviews.llvm.org/D17799
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262493 91177308-0d34-0410-b5e6-96231b3b80d8
In VisitNonTypeTemplateParamDecl, before SubstExpr with the default argument,
we should create a ConstantEvaluated ExpressionEvaluationContext. Without this,
it is possible to use a PotentiallyEvaluated ExpressionEvaluationContext; and
MaybeODRUseExprs will not be cleared when popping the context, causing
assertion failure.
This is similar to how we handle the context before SubstExpr with the
default argument, in SubstDefaultTemplateArgument.
Part of PR13986.
rdar://24480205
Differential Revision: http://reviews.llvm.org/D17576
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261803 91177308-0d34-0410-b5e6-96231b3b80d8
OMPCapturedExprDecl allows caopturing not only of fielddecls, but also
other expressions. It also allows to simplify codegen for several
clauses.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260492 91177308-0d34-0410-b5e6-96231b3b80d8
OpenMP 4.5 introduces privatization of non-static data members of current class in non-static member functions.
To correctly handle such kind of privatization a new (pseudo)declaration VarDecl-based node is added. It allows to reuse an existing code for capturing variables in Lambdas/Block/Captured blocks of code for correct privatization and codegen.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260077 91177308-0d34-0410-b5e6-96231b3b80d8
For
void f() {
union { int i; };
}
clang used to omit the RecordDecl from the anonymous union from the AST.
That's because the code creating it only called PushOnScopeChains(), which adds
it to the current DeclContext, which here is the function's DeclContext. But
RecursiveASTVisitor doesn't descent into all decls in a FunctionDecl.
Instead, for DeclContexts that contain statements, return the RecordDecl so
that it can be included in the DeclStmt containing the VarDecl for the union.
Interesting bits from the AST before this change:
|-FunctionDecl
| `-CompoundStmt
| |-DeclStmt
| | `-VarDecl 0x589cd60 <col:3> col:3 implicit used 'union (anonymous at test.cc:3:3)' callinit
After this change:
-FunctionDecl
| `-CompoundStmt
| |-DeclStmt
| | |-CXXRecordDecl 0x4612e48 <col:3, col:18> col:3 union definition
| | | |-FieldDecl 0x4612f70 <col:11, col:15> col:15 referenced i 'int'
| | `-VarDecl 0x4613010 <col:3> col:3 implicit used 'union (anonymous at test.cc:3:3)' callinit
This is now closer to how anonymous struct and unions are represented as
members of structs. It also enabled deleting some one-off code in the
template instantiation code.
Finally, it fixes a crash with ASTMatchers, see the included test case
(this fixes http://crbug.com/580749).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259079 91177308-0d34-0410-b5e6-96231b3b80d8
This new builtin template allows for incredibly fast instantiations of
templates like std::integer_sequence.
Performance numbers follow:
My work station has 64 GB of ram + 20 Xeon Cores at 2.8 GHz.
__make_integer_seq<std::integer_sequence, int, 90000> takes 0.25
seconds.
std::make_integer_sequence<int, 90000> takes unbound time, it is still
running. Clang is consuming gigabytes of memory.
Differential Revision: http://reviews.llvm.org/D13786
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252036 91177308-0d34-0410-b5e6-96231b3b80d8
consider the following:
enum E *p;
enum E { e };
The above snippet is not ANSI C because 'enum E' has not bee defined
when we are processing the declaration of 'p'; however, it is a popular
extension to make the above work. This would fail using the Microsoft
enum semantics because the definition of 'E' would implicitly have a
fixed underlying type of 'int' which would trigger diagnostic messages
about a mismatch between the declaration and the definition.
Instead, treat fixed underlying types as not fixed for the purposes of
the diagnostic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249674 91177308-0d34-0410-b5e6-96231b3b80d8
A class without a name for linkage purposes gets a name along the lines
of <unnamed-type-foo> where foo is either the name of a declarator which
defined it (like a variable or field) or a
typedef-name (like a typedef or alias-declaration).
We handled the declarator case correctly but it would fall down during
template instantiation if the declarator didn't share the tag's type.
We failed to handle the typedef-name case at all.
Instead, keep track of the association between the two and keep it up to
date in the face of template instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246469 91177308-0d34-0410-b5e6-96231b3b80d8
If a function declaration is found inside a template function as in:
template<class T> void f() {
void g(int x = T::v) except(T::w);
}
it must be instantiated along with the enclosing template function,
including default arguments and exception specification.
Together with the patch committed in r240974 this implements DR1484.
Differential Revision: http://reviews.llvm.org/D11194
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245810 91177308-0d34-0410-b5e6-96231b3b80d8
SmallVector::set_size does not reallocate the vector. Sadly I have no
idea how to test this. The vector never has more than one member in all
of the regression tests.
Found by inspection.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243987 91177308-0d34-0410-b5e6-96231b3b80d8
If a function containing a local class is instantiated, instantiate
all of local class member, including default arguments and exception
specifications.
This change fixes PR21332 and thus implements DR1484.
Differential Revision: http://reviews.llvm.org/D9990
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240974 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we'd complain about redefinition of default arguments when we
instantiated a class with a friend template that inherits its default argument,
because we propagate the default template arguemnt onto the friend when we
reload the AST.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239857 91177308-0d34-0410-b5e6-96231b3b80d8
This is just a preparatory step towards fixing visibility for default template
arguments in modules builds.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239447 91177308-0d34-0410-b5e6-96231b3b80d8
Starting from r236426 FindInstantiatedDecl may instantiate types that
are referenced before definition. This change limit the set of types
that can be instantiated by this function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237434 91177308-0d34-0410-b5e6-96231b3b80d8
This is necessary in order to allow the use of a constexpr member function, or
a member function with deduced return type, of a local class within a
surrounding instantiated function template specialization.
Patch by Michael Park!
This re-commits r236063, which was reverted in r236134, along with a fix for a
delayed template parsing bug that was exposed by this change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237064 91177308-0d34-0410-b5e6-96231b3b80d8
This is necessary in order to allow the use of a constexpr member function, or
a member function with deduced return type, of a local class within a
surrounding instantiated function template specialization.
Patch by Michael Park!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236063 91177308-0d34-0410-b5e6-96231b3b80d8
- Changed CUDALaunchBounds arguments from integers to Expr* so they can
be saved in AST for instantiation.
- Added support for template instantiation of launch_bounds attrubute.
- Moved evaluation of launch_bounds arguments to NVPTXTargetCodeGenInfo::
SetTargetAttributes() where it can be done after template instantiation.
- Added a warning on negative launch_bounds arguments.
- Amended test cases.
Differential Revision: http://reviews.llvm.org/D8985
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235452 91177308-0d34-0410-b5e6-96231b3b80d8
Reverts the code changes from r234675 but keeps the test case.
We were already maintaining a DenseMap of globals with dynamic
initializers anyway.
Fixes the test case from PR23234.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234961 91177308-0d34-0410-b5e6-96231b3b80d8
It breaks down on this test case:
void foo();
template <typename T> class C {
friend void foo();
};
inline void foo() {}
C<int> c;
We shouldn't be marking the instantiation of the friend decl of foo as
inline-specified. It may be possible to fix this by determining if the
full definition is part of the current template, but it seems better to
rever tot green until we come up with a full solution.
This reverts commit r233817, as well as follow-ups r233820 and r233821.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234355 91177308-0d34-0410-b5e6-96231b3b80d8
A function template pattern can be declared without the 'inline'
specifier and defined later with the 'inline' specifier. However, during
instantiation, we were only looking at the canonical decl to see if we
should mark the instantiated decl as inline specified. Since the
instantiated decl actually represents many pattern declarations, put the
inline specifier on the instantiation decl if any of the pattern decls
have it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233817 91177308-0d34-0410-b5e6-96231b3b80d8
of extern "C" declarations. This is simpler and vastly more efficient for
modules builds (we no longer need to load *all* extern "C" declarations to
determine if we have a redeclaration).
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231538 91177308-0d34-0410-b5e6-96231b3b80d8
The FIXME in the test is caused by TemplateDeclInstantiator::VisitCXXRecordDecl
returning a nullptr instead of creating an invalid decl. This is a common
pattern across all of TemplateDeclInstantiator, so I'm not comfortable changing
it. The reason it's not invalid in the class template is due to support for an
MSVC extension, see r137573.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225071 91177308-0d34-0410-b5e6-96231b3b80d8
than the type of a function declaration). We previously didn't instantiate
these at all! This also covers the pathological case where the only mention of
a parameter pack is within the exception specification; this gives us a second
way (other than alias templates) to reach the horrible state where a type
contains an unexpanded pack, but its canonical type does not.
This is a re-commit of r219977:
r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2.
(That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of
'this' within a template.)
r219977 was a re-commit of r217995, r218011, and r218053:
r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC.
(Incorrect overload resolution in the presence of using-declarations.)
It was re-committed in r219977 with a workaround for the MSVC rejects-valid.
r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of
unbraced range-based for loop).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221750 91177308-0d34-0410-b5e6-96231b3b80d8
of a member function of a class template that is defined outside the template.
This substitution can actually fail in some weird cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220085 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith