| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 124364
|
|
|
|
| |
llvm-svn: 124363
|
|
|
|
|
|
|
|
|
|
| |
argument but doesn't (because previous template parameters had default
arguments), clear out all of the default arguments so that we maintain
the invariant that a template parameter has a default argument only if
subsequence template parameters also have default arguments.
Fixes a crash-on-invalid <rdar://problem/8913649>.
llvm-svn: 124345
|
|
|
|
|
|
|
|
|
|
|
| |
derived-to-base cast that also casts away constness (one of the cases
for static_cast followed by const_cast) would be treated as a bit-cast
rather than a derived-to-base class, causing miscompiles and
heartburn.
Fixes <rdar://problem/8913298>.
llvm-svn: 124340
|
|
|
|
|
|
|
|
|
| |
generate meaningful [*] template argument location information.
[*] Well, as meaningful as possible, given that this entire code path
is a hack for when we've lost type-source information.
llvm-svn: 124211
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implementation used by overload resolution to support rvalue
references. The original commits caused PR9026 and some
hard-to-reproduce self-host breakage.
The only (crucial!) difference between this commit and the previous
commits is that we now properly check the SuppressUserConversions flag
before attempting to perform a second user-defined conversion in
reference binding, breaking the infinite recursion chain of
user-defined conversions.
Rvalue references should be working a bit better now.
llvm-svn: 124121
|
|
|
|
| |
llvm-svn: 124033
|
|
|
|
|
|
|
|
| |
resolution to match the latest C++0x working paper's semantics. The
implementation now matching up with the reference-binding
implementation used for initialization.
llvm-svn: 123977
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a pack expansion, e.g., the parameter pack Values in:
template<typename ...Types>
struct Outer {
template<Types ...Values>
struct Inner;
};
This new implementation approach introduces the notion of an
"expanded" non-type template parameter pack, for which we have already
expanded the types of the parameter pack (to, say, "int*, float*",
for Outer<int*, float*>) but have not yet expanded the values. Aside
from creating these expanded non-type template parameter packs, this
patch updates template argument checking and non-type template
parameter pack instantiation to make use of the appropriate types in
the parameter pack.
llvm-svn: 123845
|
|
|
|
|
|
| |
thousand other things which were (generally inadvertantly) relying on that.
llvm-svn: 123814
|
|
|
|
|
|
| |
-Wint-to-pointer-cast.
llvm-svn: 123719
|
|
|
|
|
|
|
| |
number of expansions, when we know it, and propagate that information
through Sema.
llvm-svn: 123493
|
|
|
|
|
|
| |
Remove this variable (found by clang static analyzer).
llvm-svn: 123484
|
|
|
|
|
|
| |
used; nuke all assignments and its declaration.
llvm-svn: 123483
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
involve template parameter packs at multiple template levels that
occur within the signatures members of class templates (and partial
specializations thereof). This is a work-in-progress that is deficient
in several ways, notably:
- It only works for template type parameter packs, but we need to
also support non-type template parameter packs and template template
parameter packs.
- It doesn't keep track of the lengths of the substituted argument
packs in the expansion, so it can't properly diagnose length
mismatches.
However, this is a concrete step in the right direction.
llvm-svn: 123425
|
|
|
|
|
|
|
|
|
| |
when we're actually matching a template template argument to a
template template parameter. Otherwise, use strict matching.
Fixes <rdar://problem/8859985> clang++: variadics and out-of-line definitions.
llvm-svn: 123385
|
|
|
|
|
|
|
|
| |
matching of variadic template template parameters to template
arguments. This paragraph was the subject of ISO C++ committee
document N2555: Extending Variadic Template Template Parameters.
llvm-svn: 123348
|
|
|
|
|
|
| |
bunch of duplicated checks for parameter pack/non-pack mismatches.
llvm-svn: 123343
|
|
|
|
|
|
|
| |
in ASTContext-allocated memory, copying the provided template
arguments. Use this new routine where we can. No functionality change.
llvm-svn: 123289
|
|
|
|
|
|
|
|
|
| |
number of explicit call arguments. This actually fixes an erroneous
test for [temp.deduct.partial]p11, where we were considering
parameters corresponding to arguments beyond those that were
explicitly provided.
llvm-svn: 123244
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
allows an argument pack determines via explicit specification of
function template arguments to be extended by further, deduced
arguments. For example:
template<class ... Types> void f(Types ... values);
void g() {
f<int*, float*>(0, 0, 0); // Types is deduced to the sequence int*, float*, int
}
There are a number of FIXMEs in here that indicate places where we
need to implement + test retained expansions, plus a number of other
places in deduction where we need to correctly cope with the
explicitly-specified arguments when deducing an argument
pack. Furthermore, it appears that the RecursiveASTVisitor needs to be
auditied; it's missing some traversals (especially w.r.t. template
arguments) that cause it not to find unexpanded parameter packs when
it should.
The good news, however, is that the tr1::tuple implementation now
works fully, and the tr1::bind example (both from N2080) is actually
working now.
llvm-svn: 123163
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expansions with something that is easier to use correctly: a new
template argment kind, rather than a bit on an existing kind. Update
all of the switch statements that deal with template arguments, fixing
a few latent bugs in the process. I"m happy with this representation,
now.
And, oh look! Template instantiation and deduction work for template
template argument pack expansions.
llvm-svn: 122896
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for template template argument pack expansions. This allows fun such
as:
template<template<class> class ...> struct apply_impl { /*...*/ };
template<template<class> class ...Metafunctions> struct apply {
typedef typename apply_impl<Metafunctions...>::type type;
};
However, neither template argument deduction nor template
instantiation is implemented for template template argument packs, so
this functionality isn't useful yet.
I'll probably replace the encoding of template template
argument pack expansions in TemplateArgument so that it's harder to
accidentally forget about the expansion. However, this is a step in
the right general direction.
llvm-svn: 122890
|
|
|
|
|
|
| |
functionality change
llvm-svn: 122878
|
|
|
|
|
|
|
| |
parameter packs. Also, the "no template parameters after a template
parameter pack" rule only applies to primary class templates.
llvm-svn: 122877
|
|
|
|
|
|
| |
parameters and template template parameters.
llvm-svn: 122875
|
|
|
|
|
|
|
| |
template<template<class> class ...Metafunctions>
struct apply_to_each;
llvm-svn: 122874
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specializations. We weren't dealing with any of the cases where the
type of the non-type template argument differs from the type of the
corresponding template parameter in the primary template. We would
think that the template parameter in the partial specialization was
not deducible (and warn about it, incorrectly), then fail to convert a
deduced parameter to the type of the template parameter in the partial
specialization (which may involve truncation, among other
things). Fixes PR8905.
llvm-svn: 122851
|
|
|
|
|
|
|
| |
argument. As part of this, be more careful when determining if there
are any parameter packs that cannot be expanded.
llvm-svn: 122776
|
|
|
|
|
|
|
| |
a class template partial specialiation, and look through pack
expansions when checking the conditions of C++0x [temp.class.spec]p8.
llvm-svn: 122774
|
|
|
|
|
|
| |
template partial specialization arguments.
llvm-svn: 122769
|
|
|
|
| |
llvm-svn: 122533
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
packs, e.g.,
template<typename T, unsigned ...Dims> struct multi_array;
along with semantic analysis support for finding unexpanded non-type
template parameter packs in types, expressions, and so on.
Template instantiation involving non-type template parameter packs
probably doesn't work yet. That'll come soon.
llvm-svn: 122527
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameter packs (C++0x [dcl.fct]p13), including disambiguation between
unnamed function parameter packs and varargs (C++0x [dcl.fct]p14) for
cases like
void f(T...)
where T may or may not contain unexpanded parameter packs.
llvm-svn: 122520
|
|
|
|
|
|
|
|
|
|
|
| |
specialization's template arguments against the primary template's
template arguments using the obvious, correct method of checking the
injected-class-name type (C++ [temp.class.spec]p9b3). The previous
incarnation of this comparison attempted to use its own formulation of
the injected-class-name, which is redudant and, with the introduction
of variadic templates, became wrong (again).
llvm-svn: 122508
|
|
|
|
|
|
|
|
| |
to cope with parameter packs. This is a band-aid I will be
revisiting this section when I implement declaration matching
semantics for variadic templates.
llvm-svn: 122369
|
|
|
|
| |
llvm-svn: 122325
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
whose patterns are template arguments. We can now instantiate, e.g.,
typedef tuple<pair<OuterTypes, InnerTypes>...> type;
where OuterTypes and InnerTypes are template type parameter packs.
There is a horrible inefficiency in
TemplateArgumentLoc::getPackExpansionPattern(), where we need to
create copies of TypeLoc data because our interfaces traffic in
TypeSourceInfo pointers where they should traffic in TypeLocs
instead. I've isolated in efficiency in this one routine; once we
refactor our interfaces to traffic in TypeLocs, we can eliminate it.
llvm-svn: 122278
|
|
|
|
|
|
|
|
|
|
|
|
| |
a parameter pack, check the parameter pack against each of the
template arguments it corresponds to, then pack the converted
arguments into a template argument pack. Allows us to use variadic
class templates so long as instantiation isn't required, e.g.,
template<typename... Types> struct Tuple;
Tuple<int, float> *t2;
llvm-svn: 122251
|
|
|
|
|
|
|
| |
area of printing template arguments. The functionality changes here
are limited to cases of variadic templates that aren't yet enabled.
llvm-svn: 122250
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pack expansions, e.g. given
template<typename... Types> struct tuple;
template<typename... Types>
struct tuple_of_refs {
typedef tuple<Types&...> types;
};
the type of the "types" typedef is a PackExpansionType whose pattern
is Types&.
This commit introduces support for creating pack expansions for
template type arguments, as above, but not for any other kind of pack
expansion, nor for any form of instantiation.
llvm-svn: 122223
|
|
|
|
|
|
|
| |
don't provide their own explicit visibility attributes should get them
from the template. Fixes rdar://problem/8778497.
llvm-svn: 122136
|
|
|
|
|
|
|
|
| |
non-type template parameters until we know that we have an actual
template declaration of some sort. This cannot be tested yet, but will
become important when we have template template parameter packs.
llvm-svn: 121967
|
|
|
|
| |
llvm-svn: 121964
|
|
|
|
| |
llvm-svn: 121962
|
|
|
|
|
|
| |
file in Sema. No functionality change.
llvm-svn: 121869
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IntegerLiterals
BuildExpressionFromIntegralTemplateArgument can produce malformed
IntegerLiterals with an EnumType if the template parameter type
is an EnumType. This breaks the AST printer which expects all
IntegerLiterals to have a plain integer type. Instead, give the
IntegerLiteral the enum's promotion type and wrap in an implicit cast
to the EnumType.
llvm-svn: 121862
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
whether the expression contains an unexpanded parameter pack, in the
same vein as the changes to the Type hierarchy. Compute this bit
within all of the Expr subclasses.
This change required a bunch of reshuffling of dependency
calculations, mainly to consolidate them inside the constructors and
to fuse multiple loops that iterate over arguments to determine type
dependence, value dependence, and (now) containment of unexpanded
parameter packs.
Again, testing is painfully sparse, because all of the diagnostics
will change and it is more important to test the to-be-written visitor
that collects unexpanded parameter packs.
llvm-svn: 121831
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and TemplateArgument with an operation that determines whether there
are any unexpanded parameter packs within that construct. Use this
information to diagnose the appearance of the names of parameter packs
that have not been expanded (C++ [temp.variadic]p5). Since this
property is checked often (every declaration, ever expression
statement, etc.), we extend Type and Expr with a bit storing the
result of this computation, rather than walking the AST each time to
determine whether any unexpanded parameter packs occur.
This commit is deficient in several ways, which will be remedied with
future commits:
- Expr has a bit to store the presence of an unexpanded parameter
pack, but it is never set.
- The error messages don't point out where the unexpanded parameter
packs were named in the type/expression, but they should.
- We don't check for unexpanded parameter packs in all of the places
where we should.
- Testing is sparse, pending the resolution of the above three
issues.
llvm-svn: 121724
|
|
|
|
|
|
|
|
|
| |
We should not substitute template types if the template has a dependent
context because the template argument stack is not yet fully formed.
Instead, defer substitution until the template has a non-dependent
context (i.e. instantiation of an outer template).
llvm-svn: 121491
|