This patch addresses a FIXME and has the template-parameter processing functions return a more derived common type NamedDecl (as opposed to a type needlessly higher up in the inheritance hierarchy : Decl).
llvm-svn: 321409
The standard correctly forbids various decl-specifiers that dont make sense on non-type template parameters - such as the extern in:
template<extern int> struct X;
This patch implements those restrictions (in a fashion similar to the corresponding checks on function parameters within ActOnParamDeclarator).
Credit goes to miyuki (Mikhail Maltsev) for drawing attention to this issue, authoring the initial versions of this patch, and supporting the effort to re-engineer it slightly. Thank you!
For details of how this patch evolved please see: https://reviews.llvm.org/D40705
llvm-svn: 321339
Summary:
This is so we can implement concepts per P0734R0. Relevant failing test
cases are disabled.
Reviewers: hubert.reinterpretcast, rsmith, saar.raz, nwilson
Reviewed By: saar.raz
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40380
Patch by Changyu Li!
llvm-svn: 319992
This matches MSVC's behaviour, and we already do it for class templates
since r270897.
Differential revision: https://reviews.llvm.org/D40621
llvm-svn: 319386
This bug was found via self-build on lld, and worked around
here: https://reviews.llvm.org/rL316180
The issue is that the 'using' causes the lookup to pick up the
first decl. However, when setting inherited default parameters,
we only update 'forward', not 'backward'. SO, only the newest param
list has all the information about the default arguments.
This patch ensures that the list of parameters we look through checks
the newest decl's template parameter list so it doesn't miss a default.
Differential Revision: https://reviews.llvm.org/D39127
llvm-svn: 316405
In order to identify the copy deduction candidate, I considered two approaches:
- attempt to determine whether an implicit guide is a copy deduction candidate by checking certain properties of its subsituted parameter during overload-resolution.
- using one of the many bits (WillHaveBody) from FunctionDecl (that CXXDeductionGuideDecl inherits from) that are otherwise irrelevant for deduction guides
After some brittle gymnastics w the first strategy, I settled on the second, although to avoid confusion and to give that bit a better name, i turned it into a member of an anonymous union.
Given this identification 'bit', the tweak to overload resolution was a simple reordering of the deduction guide checks (in SemaOverload.cpp::isBetterOverloadCandidate), in-line with Jason Merrill's p0620r0 drafting which made it into the working paper. Concordant with that, I made sure the copy deduction candidate is always added.
References:
See https://bugs.llvm.org/show_bug.cgi?id=34970
See http://wg21.link/p0620r0
llvm-svn: 316292
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
This reinstates r315251 and r315256, reverted in r315309 and r315308
respectively, tweaked to avoid triggering a linkage calculation when declaring
implicit special members (this exposed our pre-existing issue with typedef
names for linkage changing the linkage of types whose linkage has already been
computed and cached in more cases). A testcase for that regression has been
added in r315366.
llvm-svn: 315379
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
llvm-svn: 315251
This patch relates to: https://reviews.llvm.org/D33666 This adds support
for template parameters to be passed to the address_space attribute.
The main goal is to add further flexibility to the attribute and allow
for it to be used easily with templates.
The main additions are a new type (DependentAddressSpaceType) alongside
its TypeLoc and its mangling. As well as the logic required to support
dependent address spaces which mainly resides in TreeTransform.h and
SemaType.cpp.
llvm-svn: 314649
When a static_assert fails, dig out a specific condition to diagnose,
using the same logic that we use to find the enable_if condition to
diagnose.
llvm-svn: 313315
Summary:
r306137 made dllimport pointers to member functions non-constant. This
is correct because a load must be executed to resolve any dllimported
data. However, r306137 did not account for the use of dllimport member
function pointers used as template arguments.
This change re-lands r306137 with a template instantiation fix.
This fixes PR33570.
Reviewers: rnk, majnemer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D34714
llvm-svn: 307446
When enable_if disables a particular overload resolution candidate,
rummage through the enable_if condition to find the specific condition
that caused the failure. For example, if we have something like:
template<
typename Iter,
typename = std::enable_if_t<Random_access_iterator<Iter> &&
Comparable<Iterator_value_type<Iter>>>>
void mysort(Iter first, Iter last) {}
and we call "mysort" with "std::list<int>" iterators, we'll get a
diagnostic saying that the "Random_access_iterator<Iter>" requirement
failed. If we call "mysort" with
"std::vector<something_not_comparable>", we'll get a diagnostic saying
that the "Comparable<...>" requirement failed.
llvm-svn: 307196
definition or non-reference class type.
The crash occurs when there is a template parameter list in a class that
is missing the closing angle bracket followed by a definition of a
struct. For example:
class C0 {
public:
template<typename T, typename T1 = T // missing closing angle bracket
struct S0 {};
C0() : m(new S0<int>) {}
S0<int> *m;
};
This happens because the parsed struct is added to the scope of the
enclosing class without having its access specifier set, which results
in an assertion failure in SemaAccess.cpp later.
This commit fixes the crash by adding the parsed struct to the enclosing
file scope and marking structs as invalid if they are defined in
template parameter lists.
rdar://problem/31783961
rdar://problem/19570630
Differential Revision: https://reviews.llvm.org/D33606
llvm-svn: 306317
inferring based on the current module at the point of creation.
This should result in no functional change except when building a preprocessed
module (or more generally when using #pragma clang module begin/end to switch
module in the middle of a file), in which case it allows us to correctly track
the owning module for declarations. We can't map from FileID to module in the
preprocessed module case, since all modules would have the same FileID.
There are still a couple of remaining places that try to infer a module from a
source location; I'll clean those up in follow-up changes.
llvm-svn: 303322
When we parse a redefinition of an entity for which we have a hidden existing
declaration, make it visible in the current module instead of mapping the
current source location to its containing module.
llvm-svn: 302842
When an undeclared identifier in a context that requires a type is followed by
'<', only look for type templates when typo-correcting, tweak the diagnostic
text to say that a template name (not a type name) was undeclared, and parse
the template arguments when recovering from the error.
llvm-svn: 302732
The heuristic that we use here is:
* the left-hand side must be a simple identifier or a class member access
* the right-hand side must be '<' followed by either a '>' or by a type-id that
cannot be an expression (in particular, not followed by '(' or '{')
* there is a '>' token matching the '<' token
The second condition guarantees the expression would otherwise be ill-formed.
If we're confident that the user intended the name before the '<' to be
interpreted as a template, diagnose the fact that we didn't interpret it
that way, rather than diagnosing that the template arguments are not valid
expressions.
llvm-svn: 302615
This improves our behavior in a few ways:
* We now guarantee that if a member is marked as being a member
specialization, there will actually be a member specialization declaration
somewhere on its redeclaration chain. This fixes a crash in modules builds
where we would try to check that there was a visible declaration of the
member specialization and be surprised to not find any declaration of it at
all.
* We don't set the source location of the in-class declaration of the member
specialization to the out-of-line declaration's location until we have
actually finished merging them. This fixes some very silly looking
diagnostics, where we'd point a "previous declaration is here" note at the
same declaration we're complaining about. Ideally we wouldn't mess with the
prior declaration's location at all, but too much code assumes that the
first declaration of an entity is a reasonable thing to use as an indication
of where it was declared, and that's not really true for a member
specialization unless we fake it like this.
llvm-svn: 302596
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.
llvm-svn: 300262
- 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.
llvm-svn: 299316
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
llvm-svn: 298634
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
llvm-svn: 298410
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.
llvm-svn: 295866
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.)
llvm-svn: 295696
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).
llvm-svn: 295686
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.
llvm-svn: 295016
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.
llvm-svn: 295007
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
llvm-svn: 294697
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.
llvm-svn: 293815
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.
llvm-svn: 293207
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.
llvm-svn: 292518
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.
llvm-svn: 292426
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.
llvm-svn: 292183
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
llvm-svn: 291877
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).
llvm-svn: 291753
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.
llvm-svn: 291512
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.
llvm-svn: 291295
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
llvm-svn: 290842
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.
llvm-svn: 290792
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).
llvm-svn: 290647
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.)
llvm-svn: 290593
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.
llvm-svn: 290586
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.
llvm-svn: 290567
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.)
llvm-svn: 290511
template arguments as written rather than the canonical template arguments,
so we print more user-friendly names for template parameters.
llvm-svn: 290483
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.
llvm-svn: 290276
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
llvm-svn: 289914
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
llvm-svn: 289259
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
llvm-svn: 289091
* __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
llvm-svn: 288962
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
llvm-svn: 288682
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.
llvm-svn: 288570
arguments from a declaration; despite what the standard says, this form of
deduction should not be considering exception specifications.
llvm-svn: 288301
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
llvm-svn: 286419
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
llvm-svn: 285823
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.
llvm-svn: 284284
Original message:
"[modules] PR28752: Do not instantiate variable declarations which are not visible.
https://reviews.llvm.org/D24508
Patch developed in collaboration with Richard Smith!"
llvm-svn: 284008
Summary:
This is possible now that MapVector supports move-only values.
Depends on D25404.
Reviewers: timshen
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25405
llvm-svn: 283766
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.
llvm-svn: 280308
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. :(
llvm-svn: 280190
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.
llvm-svn: 279557
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.
llvm-svn: 279486
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
llvm-svn: 276069
After thinking about it, we don't really need to forbid
BuiltinTemplateDecls explicitly. The restriction doesn't really buy us
anything.
llvm-svn: 275078
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
llvm-svn: 274316
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.
llvm-svn: 272631
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.
llvm-svn: 272366
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.
llvm-svn: 270897
This matches what MSVC does, and should make compiles faster by avoiding to
unnecessarily emit a lot of code.
Differential Revision: http://reviews.llvm.org/D20608
llvm-svn: 270748
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.
llvm-svn: 269231
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.
llvm-svn: 268585
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.
llvm-svn: 266561
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
llvm-svn: 265868
This is a fix for https://llvm.org/bugs/show_bug.cgi?id=25561 which was a
crash on invalid. Change the handling of invalid decls to have a catch-all
case to prevent unexpecting decls from triggering an assertion.
llvm-svn: 265467
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.
llvm-svn: 264522
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.
llvm-svn: 263279
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.
llvm-svn: 262056
diagnosing when 'concept' is specified on a function or template
specialization.
Since a concept can only be applied to a function or variable template,
the concept bit is stored in TemplateDecl as a PointerIntPair.
Reviewers: rsmith, faisalv, aaron.ballman, hubert.reinterpretcast
Differential Revision: http://reviews.llvm.org/D13357
llvm-svn: 260074
Or, do not set Sema's CurContext to the template declaration's when substituting into default template arguments of said template declaration.
If we do push the template declaration context on to Sema, and the template declaration is at namespace scope, Sema can get confused and try and do odr analysis when substituting into default template arguments, even though the substitution could be occurring within a dependent context.
I'm not sure why this was being done, perhaps there was concern that if a default template argument referred to a previous template parameter, it might not be found during substitution - but all regression tests pass, and I can't craft a test that would cause it to fails (if some one does, please inform me, and i'll craft a different fix for the PR).
This patch removes a single line of code, but unfortunately adds more than it removes, because of the tests. Some day I still hope to commit a patch that removes far more lines than it adds, while leaving clang better for it ;)
Sorry that r253590 ("Change the expression evaluation context from Unevaluated to ConstantEvaluated while substituting into non-type template argument defaults") caused the PR!
llvm-svn: 258110
Summary:
Support for OpenCL 2.0 pipe type.
This is a bug-fix version for bader's patch reviews.llvm.org/D14441
Reviewers: pekka.jaaskelainen, Anastasia
Subscribers: bader, Anastasia, cfe-commits
Differential Revision: http://reviews.llvm.org/D15603
llvm-svn: 257254
underlying decls. Preserve the found declaration throughout, and only map to
the underlying declaration when we want to check whether it's the right kind.
This allows us to provide the right source location for the found declaration,
and prepares for the possibility of underlying decls with a different name
from the found decl.
llvm-svn: 256575
is complete (with an error produced if not) and a function that merely queries
whether the type is complete. Either way we'll trigger instantiation if
necessary, but only the former will diagnose and recover from missing module
imports.
The intent of this change is to prevent a class of bugs where code would call
RequireCompleteType(..., 0) and then ignore the result. With modules, we must
check the return value and use it to determine whether the definition of the
type is visible.
This also fixes a debug info quality issue: calls to isCompleteType do not
trigger the emission of debug information for a type in limited-debug-info
mode. This allows us to avoid emitting debug information for type definitions
in more cases where we believe it is safe to do so.
llvm-svn: 256049
`pass_object_size` is our way of enabling `__builtin_object_size` to
produce high quality results without requiring inlining to happen
everywhere.
A link to the design doc for this attribute is available at the
Differential review link below.
Differential Revision: http://reviews.llvm.org/D13263
llvm-svn: 254554
Also address a typo from a prior patch that performed a similar fix during Parsing of default non-type template arguments. I left the RAII ExpressionEvaluationContext variable Name as Unevaluated though we had switched the context to ConstantEvaluated.
There should be no functionality change here - since when expression evaluation context is popped off, for the most part these two contexts currently behave similarly in regards to lambda diagnostics and odr-use tracking.
Like its parsing counterpart, this patch presages the advent of constexpr lambda patches...
llvm-svn: 253590
We created a malformed TemplateSpecializationType: it was dependent but
had a RecordType as it's canonical type. This would lead getAs to
crash. r249090 worked around this but we should fix this for real by
providing a more appropriate template specialization type as the
canonical type.
This fixes PR24246.
llvm-svn: 253495
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
llvm-svn: 252036
partial specialization can perform conversions on the argument. Be sure we
start again from the original argument when checking each possible template.
llvm-svn: 249114
We used to only select an inheritance model if the pointer to member was
nullptr. Instead, select a model regardless of the member pointer's
value.
N.B. This bug was exposed by making member pointers report true for
isIncompleteType but has been latent since the member pointer scheme's
inception.
llvm-svn: 247464
It's possible for TagRedeclarations to involve decls without a name,
ie, anonymous enums. We hit some undefined behaviour if we bind these
null names to the reference here.
We never dereference the name, so it's harmless if it's null - make it
a pointer to allow that.
Fixes the Modules/submodules-merge-defs.cpp test under ubsan.
llvm-svn: 241963
an existing using shadow declaration if they define entities of the same kind
in different namespaces.
We'd previously check this consistently if the using-declaration came after the
other declaration, but not if it came before.
llvm-svn: 241428
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
This is a follow-up to r225570 which enabled adding DLL attributes when a
class template goes from explicit instantiation declaration to explicit
instantiation definition.
llvm-svn: 239375
Previously, we wouldn't call checkDLLAttribute() after the class template
specialization definition if the class template was already instantiated
by an explicit class template specialization declaration.
llvm-svn: 238266
Clang was inserting these into a dense map. While it never iterated the
dense map during normal compilation, it did when emitting a module. Fix
this by using a standard MapVector to preserve the order in which we
encounter the late parsed templates.
I suspect this still isn't ideal, as we don't seem to remove things from
this map even when we mark the templates as no longer late parsed. But
I don't know enough about this particular extension to craft a nice,
subtle test case covering this. I've managed to get the stress test to
at least do some late parsing and demonstrate the core problem here.
This patch fixes the test and provides deterministic behavior which is
a strict improvement over the prior state.
I've cleaned up some of the code here as well to be explicit about
inserting when that is what is actually going on.
llvm-svn: 233264
MS compiler emits no errors in case of explicit specializations outside declaration enclosing namespaces, even when language extensions are disabled.
The patch is to suppress errors and emit extension warnings if explicit specializations are not declared in the corresponding namespaces.
This fixes PR13738.
Patch by Alexey Frolov.
Differential Revision: http://reviews.llvm.org/D8283
llvm-svn: 232800
and only update the orginal list on a valid arugment list. When checking an
individual expression template argument, and conversions are required, update
the expression in the template argument. Since template arguments are
speculatively checked, the copying of the template argument list prevents
updating the template arguments when the list does not match the template.
Additionally, clean up the integer checking code in the template diffing code.
The code performs unneccessary conversions from APSInt to APInt.
Fixes PR21758.
This essentially reverts r224770 to recommits r224667 and r224668 with extra
changes to prevent the template instantiation problems seen in PR22006.
A test to catch the discovered problem is also added.
llvm-svn: 226983
Clang would previously become confused and crash here.
It does not make a lot of sense to export these, so warning seems appropriate.
MSVC will export some member functions for this kind of specializations, whereas
MinGW ignores the dllexport-edness. The latter behaviour seems better.
Differential Revision: http://reviews.llvm.org/D6984
llvm-svn: 226208
When a non-type template argument expression needs a conversion to change it
into the argument type, preserve that information by remaking the
TemplateArgument with an expression that has those conversions. Also a small
fix to template type diffing to handle the extra conversions in some cases.
llvm-svn: 224667
Consider a template class with attributes on a method, and an explicit
specialization of that method:
template <int>
struct A {
void foo() final;
};
template <>
void A<0>::foo() {}
In this example, the attribute is `final`, but it might also be an
__attribute__((visibility("foo"))), noreturn, inline, etc. clang's current
behavior is to strip all attributes, which for some attributes is wrong
(the snippet above allows a subclass of A<0> to override the final method, for
example) and for others disagrees with gcc.
So stop dropping attributes. r95845 added this code without a test case, and
r176728 added the code for dropping attributes on parameters (with tests, but
they still pass).
As an additional wrinkle, do drop dllimport and dllexport, since that's how
these two attributes work. (This is covered by existing tests.)
Fixes PR21942.
The approach is by Richard Smith, initial analysis and typing was done by me.
With this, clang also matches GCC and EDG on all attributes Richard tested.
llvm-svn: 224651
This reverts commit r224451. It caused us to reject some valid existing
code.
This code appears to run in non-error cases as well as error cases. If
the scope of a DependentScopeDeclRefExpr is still incomplete it probably
means we still have more instantiation to do.
llvm-svn: 224526
exact type match for deduced template arguments, and be sure to produce correct
canonical TemplateArgument representations to enable correct redeclaration
matching.
llvm-svn: 224456
A DependentScopeDeclRefExpr should always have a nested name specifier.
During template instantiation, if we found that the named context was
incomplete, we would previously build a DependentScopeDeclRefExpr with
an empty qualifier.
This error recovery path has been asserting for some time. The other
error codepaths use ExprError, so we can do the same.
Fixes PR21864.
llvm-svn: 224451
We don't yet support pointer-to-member template arguments that have undergone
pointer-to-member conversions, mostly because we don't have a mangling for them yet.
llvm-svn: 222807
expansion into a parameter pack; we know that we're still filling in that
parameter's arguments. Previously, if we hit this case for an alias template,
we'd try to substitute using non-canonical template arguments.
llvm-svn: 221832
penultimate parameter of a template parameter list, where the last parameter is
itself a pack, and build a bogus empty final pack argument.
llvm-svn: 221748
According to C++ standard if an exception-specification is specified in an explicit instantiation directive, it shall be compatible with the exception-specifications of other declarations of that function. This patch adds checks for this.
Differential Revision: http://reviews.llvm.org/D5822
llvm-svn: 221448
Plumb through the full QualType of the TemplateArgument::Declaration, as
it's insufficient to only know whether the type is a reference or
pointer (that was necessary for mangling, but insufficient for debug
info). This shouldn't increase the size of TemplateArgument as
TemplateArgument::Integer is still longer by another 32 bits.
Several bits of code were testing that the reference-ness of the
parameters matched, but this seemed to be insufficient (various other
features of the type could've mismatched and wouldn't've been caught)
and unnecessary, at least insofar as removing those tests didn't cause
anything to fail.
(Richard - perchaps you can hypothesize why any of these checks might
need to test reference-ness of the parameters (& explain why
reference-ness is part of the mangling - I would've figured that for the
reference-ness to be different, a prior template argument would have to
be different). I'd be happy to add them in/beef them up and add test
cases if there's a reason for them)
llvm-svn: 219900
We build a NestedNameSpecifier that records the CXXRecordDecl in which
__super appeared. Name lookup is performed in all base classes of the
recorded CXXRecordDecl. Use of __super is allowed only inside class and
member function scope.
llvm-svn: 218484
The warning warns on TypedefNameDecls -- typedefs and C++11 using aliases --
that are !isReferenced(). Since the isReferenced() bit on TypedefNameDecls
wasn't used for anything before this warning it wasn't always set correctly,
so this patch also adds a few missing MarkAnyDeclReferenced() calls in
various places for TypedefNameDecls.
This is made a bit complicated due to local typedefs possibly being used only
after their local scope has closed. Consider:
template <class T>
void template_fun(T t) {
typename T::Foo s3foo; // YYY
(void)s3foo;
}
void template_fun_user() {
struct Local {
typedef int Foo; // XXX
} p;
template_fun(p);
}
Here the typedef in XXX is only used at end-of-translation unit, when YYY in
template_fun() gets instantiated. To handle this, typedefs that are unused when
their scope exits are added to a set of potentially unused typedefs, and that
set gets checked at end-of-TU. Typedefs that are still unused at that point then
get warned on. There's also serialization code for this set, so that the
warning works with precompiled headers and modules. For modules, the warning
is emitted when the module is built, for precompiled headers each time the
header gets used.
Finally, consider a function using C++14 auto return types to return a local
type defined in a header:
auto f() {
struct S { typedef int a; };
return S();
}
Here, the typedef escapes its local scope and could be used by only some
translation units including the header. To not warn on this, add a
RecursiveASTVisitor that marks all delcs on local types returned from auto
functions as referenced. (Except if it's a function with internal linkage, or
the decls are private and the local type has no friends -- in these cases, it
_is_ safe to warn.)
Several of the included testcases (most of the interesting ones) were provided
by Richard Smith.
(gcc's spelling -Wunused-local-typedefs is supported as an alias for this
warning.)
llvm-svn: 217298
declared, rather than putting them into the template parameter scope. We
previously had *no record* in the scope for class template declarations, once
those declarations completed and their template parameter scopes were popped.
This in turn caused us to be unable to merge class template declarations that
were declared in the global scope (where we use scope lookup rather than
DeclContext lookup for merging), when loading a module.
llvm-svn: 216311
ExtWarn/Warnings. Mostly the name of the warning was changed to match the
semantics, but in the PR20356 cases, the warning was about valid code, so the
diagnostic was changed from ExtWarn to Warning instead.
llvm-svn: 213443
Previously dllimport variables inside of template arguments relied on
not using the C++11 codepath when -fms-compatibility was set.
While this allowed us to achieve compatibility with MSVC, it did so at
the expense of MingW.
Instead, try to use the DeclRefExpr we dig out of the template argument.
If it has the dllimport attribute, accept it and skip the C++11
null-pointer check.
llvm-svn: 211766
This is a follow-up to David's r211677. For the following code,
we would end up referring to 'foo' in the initializer for 'arr',
and then fail to link, because 'foo' is dllimport and needs to be
accessed through the __imp_?foo.
__declspec(dllimport) extern const char foo[];
const char* f() {
static const char* const arr[] = { foo };
return arr[0];
}
Differential Revision: http://reviews.llvm.org/D4299
llvm-svn: 211736
The compilation pipeline doesn't actually need to know about the high-level
concept of diagnostic mappings, and hiding the final computed level presents
several simplifications and other potential benefits.
The only exceptions are opportunistic checks to see whether expensive code
paths can be avoided for diagnostics that are guaranteed to be ignored at a
certain SourceLocation.
This commit formalizes that invariant by introducing and using
DiagnosticsEngine::isIgnored() in place of individual level checks throughout
lex, parse and sema.
llvm-svn: 211005
Summary:
'sizeof' is a UnaryExprOrTypeTrait, and it can contain either a type or
an expression. This change threads a RecoveryTSI parameter through the
layers between TransformUnaryExprOrTypeTrait the point at which we look
up the type. If lookup finds a single type result after instantiation,
we now build TypeSourceInfo for it just like a normal transformation
would.
This fixes the last error in the hello world ATL app that I've been
working with, and it now links and runs with clang. Please try it and
file bugs!
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4108
llvm-svn: 210855
While matching a non-type template argument against a known template
type parameter we now modify the AST's TemplateArgumentLoc to assume the
user wrote typename. Under -fms-compatibility, we downgrade our
diagnostic from an error to an extwarn.
Reviewed by: rsmith
Differential Revision: http://reviews.llvm.org/D4049
llvm-svn: 210607
results in a template having too many arguments, but all the trailing arguments
are packs, that's OK if we have a partial pack substitution: the trailing pack
expansions may end up empty.
llvm-svn: 210350
gets explicitly specialized, don't reuse the previous class template
specialization declaration as a new declaration. The benefit here is fairly
marginal, it harms source fidelity, and this is horrible to model if the
specialization was imported from another module (without this change, it
asserts or worse).
llvm-svn: 209552
A template declaration of a template name can be null in case we have a dependent name or a set of function templates.
Hence use dyn_cast_or_null instead of dyn_cast. Also improve the diagnostic emitted in this case.
llvm-svn: 208313
after we've already instantiated a definition for the function, pass it to the
ASTConsumer again so that it knows the specialization kind has changed and can
update the function's linkage.
This only matters if we instantiate the definition of the function before we
reach the end of the TU; this can happen in at least three different ways:
C++11 constexpr functions, C++14 deduced return types, and functions
instantiated within modules.
llvm-svn: 207152
that looks like it might be an explicit specialization, don't recover as an
explicit specialization (bypassing the check that would reject that).
llvm-svn: 206444
For namespaces, this is consistent with mangling and GCC's debug info
behavior. For structs, GCC uses <anonymous struct> but we prefer
consistency between all anonymous entities but don't want to confuse
them with template arguments, etc, so we'll just go with parens in all
cases.
llvm-svn: 205398
template parameters, don't look for parameters of outer templates. If a problem
is found in a default template argument, point the diagnostic at the partial
specialization (with a note pointing at the default argument) instead of
pointing it at the default argument and leaving it unclear which partial
specialization os problematic.
llvm-svn: 201031
Properly determine the inheritance model when dealing with nullptr:
- If a nullptr template argument is being checked against
pointer-to-member parameter, nail down an inheritance model.
N.B. We will chose an inheritance model even if we won't ultimately
choose the template to instantiate! Cooky, right?
- Null pointer-to-datamembers have a virtual base table offset of -1,
not zero. Previously, we chose an offset of 0.
llvm-svn: 200920
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
llvm-svn: 199686
issue 1430. Don't allow a pack expansion to be used as an argument to an alias
template unless the corresponding parameter is a parameter pack.
llvm-svn: 198833
type-specifier in C++. Some checks will assert in this case otherwise (in
particular, the access specifier may be missing if this happens inside a class
definition, due to a violation of an AST invariant).
llvm-svn: 198721
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
is specialized by an explicit specialization, start from the first declaration
in case we've got a member of a class template (redeclarations might not number
the template parameters the same way).
Our recover here is still far from ideal.
llvm-svn: 197305
The standard is pretty clear on what it allows inside of template
arguments for non-type template parameters of pointer-to-member.
They must be of the form &qualified-id and cannot come from sources like
constexpr VarDecls or things of that nature.
This fixes PR18192.
llvm-svn: 196852
nested-name-specifier, rather than crashing. (In fact, reject all
literal-operator-ids that have a non-namespace nested-name-specifier). The
grammar doesn't allow these in some cases, and in other cases does allow them
but instantiation will always fail.
llvm-svn: 196443
We would fail to instantiate them when the surrounding function was
instantiated. Instantiate the class and add it's members to the list of
pending instantiations, they should be resolved when we are finished
with the function's body.
This fixes PR9685.
llvm-svn: 195827
The previous patches tried to deduce the correct function type. I now realize
this is not possible in general. Consider
class foo {
template <typename T> static void bar(T v);
};
extern template void foo::bar(const void *);
We will only know that bar is static after a lookup, so we have to handle this
in the template instantiation code.
This patch reverts my previous two changes (but not the tests) and instead
handles the issue in DeduceTemplateArguments.
llvm-svn: 195154
We only considered FieldDecl and CXXMethodDecl as appropriate which
would cause us to believe the IndirectFieldDecl corresponded to an
argument of it's field type instead of a pointer-to-member type.
This fixes PR17696.
llvm-svn: 193461
We would not identify pointer-to-member construction in a non-type
template argument if it was either a FieldDecl or a CXXMethodDecl.
However, this would incorrectly reject declarations that were injected
via an IndirectFieldDecl (e.g. a field inside of an anonymous union).
This fixes PR17657.
llvm-svn: 193203
Summary:
Enforce the rule in C++11 [temp.mem]p2 that local classes cannot have
member templates.
This fixes PR16947.
N.B. C++14 has slightly different wording to afford generic lambdas
declared inside of functions.
Fun fact: Some formulations of local classes with member templates
would cause clang to crash during Itanium mangling, such as the
following:
void outer_mem() {
struct Inner {
template <typename = void>
struct InnerTemplateClass {
static void itc_mem() {}
};
};
Inner::InnerTemplateClass<>::itc_mem();
}
Reviewers: eli.friedman, rsmith, doug.gregor, faisalv
Reviewed By: doug.gregor
CC: cfe-commits, ygao
Differential Revision: http://llvm-reviews.chandlerc.com/D1866
llvm-svn: 193144
Faisal Vali