Doing so thwarts template type deduction. Instead, substitute the pack directly
by picking "slice 0" of the resulting expansion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300805 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts an attempt to check that types match when matching a
dependently-typed non-type template parameter. (This comes up when matching the
parameters of a template template parameter against the parameters of a
template template argument.)
The matching rules here are murky at best. Our behavior after this revert is
definitely wrong for certain C++17 features (for 'auto' template parameter
types within the parameter list of a template template argument in particular),
but our behavior before this revert is wrong for some pre-existing testcases,
so reverting to our prior behavior seems like our best option.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300262 91177308-0d34-0410-b5e6-96231b3b80d8
- also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17.
- update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299316 91177308-0d34-0410-b5e6-96231b3b80d8
Correct class-template deprecation behavior
Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case:
template<typename T> [[deprecated]] class Foo{}; Foo<int> f;
This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute.
Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute.
Previous DiffRev: https://reviews.llvm.org/D27486, was reverted.
This patch fixes the issues brought up here by the reverter: https://reviews.llvm.org/rL298410
Differential Revision: https://reviews.llvm.org/D31245
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298634 91177308-0d34-0410-b5e6-96231b3b80d8
Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case:
template<typename T> [[deprecated]] class Foo{}; Foo<int> f;
This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute.
Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute.
Differential Revision: https://reviews.llvm.org/D27486
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298410 91177308-0d34-0410-b5e6-96231b3b80d8
A 'decltype(auto)' parameter can match any other kind of non-type template
parameter, so should be usable in place of any other parameter in a template
template argument. The standard is sadly extremely unclear on how this is
supposed to work, but this seems like the obviously-correct result.
It's less clear whether an 'auto' parameter should be able to match
'decltype(auto)', since the former cannot be used if the latter turns out to be
used for a reference type, but if we disallow that then consistency suggests we
should also disallow 'auto' matching 'T' for the same reason, defeating
intended use cases of the feature.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295866 91177308-0d34-0410-b5e6-96231b3b80d8
template deduction guides for class template argument deduction.
Ensure that we have a local instantiation scope for tracking the instantiated
parameters. Additionally, unusually, we're substituting at depth 1 and leaving
depth 0 alone; make sure that we don't reduce template parameter depth by 2 for
inner parameters in the process. (This is probably also broken for alias
templates in the case where they're expanded within a dependent context, but
this patch doesn't fix that.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295696 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation.
In preparation for converting the template stack to a more general context
stack (so we can include context notes for other kinds of context).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295686 91177308-0d34-0410-b5e6-96231b3b80d8
guide from a constructor.
The purpose of this change is to avoid triggering instantiation of the class
when substituting back into the deduction guide if it uses a typedef member.
We will still instantiate the class if the constructor (explicitly or
implicitly, directly or indirectly) uses the current instantiation in a way
that we can't canonicalize out, but that seems unavoidable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295016 91177308-0d34-0410-b5e6-96231b3b80d8
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
Summary:
This adds associated constraints as a property of class templates.
An error is produced if redeclarations are not similarly constrained.
Reviewers: rsmith, faisalv, aaron.ballman
Reviewed By: rsmith
Subscribers: cfe-commits, nwilson
Differential Revision: https://reviews.llvm.org/D25674
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@294697 91177308-0d34-0410-b5e6-96231b3b80d8
name. If the dependent name happened to end in a template-id (X<T>::Y<U>), we
would fail to notice that the 'typename' keyword is missing when resolving it
to a type.
It turns out that GCC has a similar bug. If this shows up in much real code, we
can easily downgrade this to an ExtWarn.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293815 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
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
Diagnose the case when a dependent template name instantiates to an
injected-class-name outside a nested-name-specifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292545 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
This rule permits the injected-class-name of a class template to be used as
both a template type argument and a template template argument, with no extra
syntax required to disambiguate.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292426 91177308-0d34-0410-b5e6-96231b3b80d8
The rules around typechecking deduced template arguments during partial
ordering are not clear, and while the prior behavior does not seem to be
correct (it doesn't follow the general model of partial ordering where each
template parameter is replaced by a non-dependent but unique value), the new
behavior is also not clearly right and breaks some existing idioms.
The new behavior is retained for dealing with non-type template parameters
with 'auto' types, as without it even the most basic uses of that feature
don't work. We can revisit this once CWG has come to an agreement on how
partial ordering with 'auto' non-type template parameters is supposed to
work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292183 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
In the case where the template class itself is already `dllexport`, the
implicit instantiation will have already emitted all members. When we
check the explicit instantiation definition, the `Specialization` will
have inherited the `dllexport` attribute, so we'll attempt to emit all
members for a second time, which causes an assertion failure. Restrict
the exporting to when the `dllexport` attribute is newly introduced by
the explicit instantiation definition.
Fixes PR31608.
Differential Revision: https://reviews.llvm.org/D28590
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291877 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
properly even when a non-type template parameter has a dependent type.
Previously, if a non-type template parameter was dependent, but not dependent
on an outer level of template parameter, we would not match the type of the
parameter. Under [temp.arg.template], we are supposed to check that the types
are equivalent, which means checking for syntactic equivalence in the dependent
case.
This also fixes some accepts-invalids when passing templates with auto-typed
non-type template parameters as template template arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291512 91177308-0d34-0410-b5e6-96231b3b80d8
dependent context and can't be used in a constant expression.
Per C++ [temp.inst]p2, "the instantiation of a static data member does not
occur unless the static data member is used in a way that requires the
definition to exist".
This doesn't /quite/ match that, as we still instantiate static data members
that are usable in constant expressions even if the use doesn't require a
definition. A followup patch will fix that for both variables and functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291295 91177308-0d34-0410-b5e6-96231b3b80d8
In many translation units I have tried, the calls to isIgnored() removed
in this patch are more expensive than doing the analysis that is behind
it. The speed-up in translation units I have tried is between 10 and
20%.
Review: https://reviews.llvm.org/D28208
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290842 91177308-0d34-0410-b5e6-96231b3b80d8
to be specified for a template template parameter whenever the parameter is at
least as specialized as the argument (when there's an obvious and correct
mapping from uses of the parameter to uses of the argument). For example, a
template with more parameters can be passed to a template template parameter
with fewer, if those trailing parameters have default arguments.
This is disabled by default, despite being a DR resolution, as it's fairly
broken in its current state: there are no partial ordering rules to cope with
template template parameters that have different parameter lists, meaning that
code that attempts to decompose template-ids based on arity can hit unavoidable
ambiguity issues.
The diagnostics produced on a non-matching argument are also pretty bad right
now, but I aim to improve them in a subsequent commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290792 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
specialized than the primary template. (Put another way, if we imagine there
were a partial specialization matching the primary template, we should never
select it if some other partial specialization also matches.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290593 91177308-0d34-0410-b5e6-96231b3b80d8
template parameters of reference type basically doesn't work, because we're
always deducing from an argument expression of non-reference type, so the type
of the deduced expression never matches. Instead, compare the type of an
expression naming the parameter to the type of the argument.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290586 91177308-0d34-0410-b5e6-96231b3b80d8
dependent contexts when processing the template in C++11 and C++14, just like
we do in C++98 and C++1z. This allows us to diagnose invalid templates earlier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290567 91177308-0d34-0410-b5e6-96231b3b80d8
non-type template parameters.
During partial ordering, when checking the substituted deduced template
arguments match the original, check the types of non-type template arguments
match even if they're dependent. The only way we get dependent types here is if
they really represent types of the other template (which are supposed to be
modeled as being substituted for unique, non-dependent types).
In order to make this work for auto-typed non-type template arguments, we need
to be able to perform auto deduction even when the initializer and
(potentially) the auto type are dependent, support for which is the bulk of
this patch. (Note that this requires the ability to deduce only a single level
of a multi-level dependent type.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290511 91177308-0d34-0410-b5e6-96231b3b80d8
template arguments as written rather than the canonical template arguments,
so we print more user-friendly names for template parameters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290483 91177308-0d34-0410-b5e6-96231b3b80d8
argument even if the expression is value-dependent (we need to suppress the
final portion of the narrowing check, but the rest of the checking can still be
done eagerly).
This affects template template argument validity and partial ordering under
p0522r0.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290276 91177308-0d34-0410-b5e6-96231b3b80d8
expressions in a function or class template.
This patch makes the following changes:
- Create a DependentScopeDeclRefExpr for the default argument instead of
a CXXDependentScopeMemberExpr.
- Pass CombineWithOuterScope=true so that the outer scope in which the
enum is declared is searched for the instantiation of the enum.
This is the first part of https://reviews.llvm.org/D23096. Fixes PR28795
rdar://problem/27535319
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289914 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
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
On MSVC, if an implicit instantiation already exists and an explicit
instantiation definition with a DLL attribute is created, the DLL
attribute still takes effect. Make clang match this behavior for
exporting.
Differential Revision: https://reviews.llvm.org/D26657
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288682 91177308-0d34-0410-b5e6-96231b3b80d8
An explicit template specialization can cause the implicit template
specialization of a type which inherits the attributes. In such a case, we
would end up with a delayed template specialization for a dll exported type
which we would fail to reference. This would trigger an assertion.
We now propagate the dll storage attributes through the inheritance
chain. Only after having done so do we reference the delayed template
specializations. This allows any implicit specializations which inherit dll
storage to also be referenced.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288570 91177308-0d34-0410-b5e6-96231b3b80d8
arguments from a declaration; despite what the standard says, this form of
deduction should not be considering exception specifications.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288301 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to r284288, make the Itanium ABI follow MS ABI dllexport
semantics in the case of an explicit instantiation declaration followed
by a dllexport explicit instantiation definition.
Differential Revision: https://reviews.llvm.org/D26471
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286419 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
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
export-declarations. These don't yet have an effect on name visibility;
we still export everything by default.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280999 91177308-0d34-0410-b5e6-96231b3b80d8
explicit specialization to a warning for C++98 mode (this is a defect report
resolution, so per our informal policy it should apply in C++98), and turn
the warning on by default for C++11 and later. In all cases where it fires, the
right thing to do is to remove the pointless explicit instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280308 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 declaration for arrays, aggregate-like structs, tuple-like
types, and (as an extension) for complex and vector types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278435 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
After thinking about it, we don't really need to forbid
BuiltinTemplateDecls explicitly. The restriction doesn't really buy us
anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275078 91177308-0d34-0410-b5e6-96231b3b80d8
We hit over stringent asserts when trying to diagnose. Loosen them as
appropriate.
This fixes PR28494.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275047 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@274475 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a __nth_element builtin that allows fetching the n-th type of a
parameter pack with very little compile-time overhead. The patch was inspired by
r252036 and r252115 by David Majnemer, which add a similar __make_integer_seq
builtin for efficiently creating a std::integer_sequence.
Reviewed as D15421. http://reviews.llvm.org/D15421
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274316 91177308-0d34-0410-b5e6-96231b3b80d8
See https://llvm.org/bugs/show_bug.cgi?id=28100.
In r266561 when I implemented allowing explicit specializations of function templates to override deleted status, I mistakenly assumed (and hence introduced a violable assertion) that when an explicit specialization was being declared, the corresponding specialization of the most specialized function template that it would get linked to would always be the one that was implicitly generated - and so if it was marked as 'deleted' it must have inherited it from the primary template and so should be safe to reset its deleted status, and set it to being an explicit specialization. Obviously during redeclaration of a deleted explicit specialization, in order to avoid a recursive reset, we need to check that the previous specialization is not an explicit specialization (instead of assuming and asserting it) and that it hasn't been referenced, and so only then is it safe to reset its 'deleted' status.
All regression tests pass.
Thanks to Zhendong Su for reporting the bug and David Majnemer for tracking it to my commit r266561, and promptly bringing it to my attention.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272631 91177308-0d34-0410-b5e6-96231b3b80d8
Crash reported in PR28023 is caused by the fact that non-type template
parameters are found by tag name lookup. In the code provided in that PR:
template<int V> struct A {
struct B {
template <int> friend struct V;
};
};
the template parameter V is found when lookup for redeclarations of 'struct V'
is made. Latter on the error about shadowing of 'V' is emitted but the semantic
context of 'struct V' is already determined wrong: 'struct A' instead of
translation unit.
The fix moves the check for shadowing toward the beginning of the method and
thus prevents from wrong context calculations.
This change fixes PR28023.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272366 91177308-0d34-0410-b5e6-96231b3b80d8
Also make explicit instantiation decls not apply to nested classes when
targeting MSVC. That dll attributes are not inherited by inner classes
might be the explanation for MSVC's behaviour here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270897 91177308-0d34-0410-b5e6-96231b3b80d8
This is in preparation for C++ P0136R1, which switches the model for inheriting
constructors over from synthesizing a constructor to finding base class
constructors (via using shadow decls) when looking for derived class
constructors.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269231 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
template<class T> void f(T) = delete;
template<> void f(int); // OK.
f(3); // OK
Implementation strategy:
When an explicit specialization of a function template, a member function template or a member function of a class template is declared, clang first implicitly instantiates the declaration of a specialization from the templated-entity being explicitly specialized (since their signatures must be the same) and then links the explicit specialization being declared as a redeclaration of the aforementioned specialization.
The problem was that when clang 'implicitly instantiates' the initial specialization, it marks the corresponding FunctionDecl as deleted if the corresponding templated-entity was deleted, rather than waiting to see whether the explicit specialization being declared provides a non-deleted body. (The eager marking of delete has advantages during overload resolution I suppose, where we don't have to try and instantiate a definition of the function to see if it is deleted).
The present fix entails recognizing that when clang knows that an explicit specialization is being declared (for whichever templated-entity), the prior implicit instantiation should not inherit the 'deleted' status, and so we reset it to false.
I suppose an alternative fix (amongst others) could consider creating a new context (ExplicitSpecializationDeclarationSubstitution or some such) that is checked during template-argument-deduction and final substitution, and avoid inheriting the deleted status during declaration substitution. But while conceptually cleaner, that would be a slightly more involved change (as could be some of the other alternatives: such as avoid tagging implicit specializations as deleted, and check their primary templates for the deleted status where needed), and so I chose a different path. Hopefully it'll prove to not be a bad choice.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266561 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: A program shall not declare an explicit instantiation (14.8.2), an explicit specialization (14.8.3), or a partial specialization of a concept definition.
Reviewers: rsmith, hubert.reinterpretcast, faisalv, aaron.ballman
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18221
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265868 91177308-0d34-0410-b5e6-96231b3b80d8
The prior diagnostic (err_template_arg_not_class_template) would state that the template argument to a template template parameter can only be a class template, when it can also be a template alias. The newly renamed diagnostic (err_template_arg_not_valid_template) mentions template aliases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264522 91177308-0d34-0410-b5e6-96231b3b80d8
This feature works outside of templates by forming a DeclRefExpr to a
FieldDecl instead of a MemberExpr, which requires a base object in
addition to the FieldDecl.
Previously, while building up the template AST before instantiation, we
formed a CXXDependentScopeMemberExpr, which always instantiates to a
MemberExpr. Now, in unevaluated contexts we form a
DependentScopeDeclRefExpr, which is a more flexible node that can
instantiate to either a MemberExpr or a DeclRefExpr depending on lookup
results.
Fixes PR26893.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263279 91177308-0d34-0410-b5e6-96231b3b80d8
Relands r260194 with a fix. If we have a template that transitions from
an extern template to an explicitly instantiated dllexport template, we
would add that class to the delayed exported class list without flushing
it.
For explicit instantiations, we can just flush the list of delayed
classes immediately. We don't have to worry about the bug fixed in
r260194 in this case because explicit instantiations can only occur at
file and namespace scope.
Fixes PR26490.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262056 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith