| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
whether C++ exceptions are enabled, not exceptions in general. PR9358.
llvm-svn: 126820
|
|
|
|
|
|
|
|
| |
of an expansion, and we have a paramameter that is not a parameter
pack, don't suppress substitution of parameter packs within this
context.
llvm-svn: 126819
|
|
|
|
| |
llvm-svn: 126599
|
|
|
|
| |
llvm-svn: 126037
|
|
|
|
|
|
|
|
|
|
| |
parameter type to see what's behind it, so that we don't end up
printing silly things like "float const *" when "const float *" would
make more sense. Also, replace the pile of "isa" tests with a simple
switch enumerating all of the cases, making a few more obvious cases
use prefix qualifiers.
llvm-svn: 125729
|
|
|
|
| |
llvm-svn: 124863
|
|
|
|
|
|
| |
[temp.param]p9 and C++ DR226. Fixes PR8747.
llvm-svn: 124856
|
|
|
|
|
|
|
|
|
|
| |
it's okay for the following template parameters to not have default
arguments (since those template parameters can still be
deduced). Also, downgrade the error about default template arguments
in function templates to an extension warning, since this is a
harmless C++0x extension.
llvm-svn: 124855
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 124295
|
|
|
|
|
|
|
|
| |
T) when taking the address of an overloaded function or matching a
specialization to a template (C++0x [temp.deduct.type]p10). Fixes
PR9044.
llvm-svn: 124197
|
|
|
|
| |
llvm-svn: 124031
|
|
|
|
|
|
| |
f(T&) and f(T&&).
llvm-svn: 123981
|
|
|
|
| |
llvm-svn: 123967
|
|
|
|
|
|
|
|
|
|
|
| |
call (C++0x [temp.deduct.call]p3).
As part of this, start improving the reference-binding implementation
used in the computation of implicit conversion sequences (for overload
resolution) to reflect C++0x semantics. It still needs more work and
testing, of course.
llvm-svn: 123966
|
|
|
|
|
|
|
| |
overload resolution, so that we only use that number of call arguments
for partial ordering. Fixes PR9006, a recent regression.
llvm-svn: 123861
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
together. In particular:
- Handle the use of captured parameter pack names within blocks
(BlockDeclRefExpr understands parameter packs now)
- Handle the declaration and expansion of parameter packs within a block's
parameter list, e.g., ^(Args ...args) { ... })
- Handle instantiation of blocks where the return type was not
explicitly specified. (unrelated, but necessary for my tests).
Together, these fixes should make blocks and variadic templates work
reasonably well together. Note that BlockDeclRefExpr is still broken
w.r.t. its computation of type and value dependence, which will still
cause problems for blocks in templates.
llvm-svn: 123849
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
non-variadic function template over a variadic one. This matches GCC
and the intent of the C++0x wording, in a way that I think is likely
to be acceptable to the committee.
llvm-svn: 123581
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template template parameter pack that cannot be fully expanded because
its enclosing pack expansion could not be expanded. This form of
TemplateName plays the same role as SubstTemplateTypeParmPackType and
SubstNonTypeTemplateParmPackExpr do for template type parameter packs
and non-type template parameter packs, respectively.
We should now handle these multi-level pack expansion substitutions
anywhere. The largest remaining gap in our variadic-templates support
is that we cannot cope with non-type template parameter packs whose
type is a pack expansion.
llvm-svn: 123521
|
|
|
|
|
|
|
|
|
| |
that captures the substitution of a non-type template argument pack
for a non-type template parameter pack within a pack expansion that
cannot be fully expanded. This follows the approach taken by
SubstTemplateTypeParmPackType.
llvm-svn: 123506
|
|
|
|
|
|
|
| |
number of expansions, when we know it, and propagate that information
through Sema.
llvm-svn: 123493
|
|
|
|
|
|
| |
contain multiple parameter packs at different levels.
llvm-svn: 123488
|
|
|
|
|
|
| |
it will expand to, if known. Propagate this information throughout Sema.
llvm-svn: 123470
|
|
|
|
|
|
|
|
| |
expansion in it, we may end up instantiating to an empty
expression-list. In this case, the variable is uninitialized; tweak
the instantiation logic to handle this case. Fixes PR8977.
llvm-svn: 123449
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expansion, when it is known due to the substitution of an out
parameter pack. This allows us to properly handle substitution into
pack expansions that involve multiple parameter packs at different
template parameter levels, even when this substitution happens one
level at a time (as with partial specializations of member class
templates and the signatures of member function templates).
Note that the diagnostic we provide when there is an arity mismatch
between an outer parameter pack and an inner parameter pack in this
case isn't as clear as the normal diagnostic for an arity
mismatch. However, this doesn't matter because these cases are very,
very rare and (even then) only typically occur in a SFINAE context.
The other kinds of pack expansions (expression, template, etc.) still
need to support optional tracking of the number of expansions, and we
need the moral equivalent of SubstTemplateTypeParmPackType for
substituted argument packs of template template and non-type template
parameters.
llvm-svn: 123448
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 123349
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
the proposed resolution to core isue 692. I'm not certain which way
we'll go on this one.
llvm-svn: 123331
|
|
|
|
|
|
|
|
|
| |
another pack expansion type. This can happen when rebuilding types in
the current instantiation.
Fixes <rdar://problem/8848837> (Clang crashing on libc++ <functional>).
llvm-svn: 123316
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and function templates that contain variadic templates. This involves
three small-ish changes:
(1) When transforming a pack expansion, if the transformed argument
still contains unexpanded parameter packs, build a pack
expansion. This can happen during the substitution that occurs into
class template partial specialiation template arguments during
partial ordering.
(2) When performing template argument deduction where the argument
is a pack expansion, match against the pattern of that pack
expansion.
(3) When performing template argument deduction against a non-pack
parameter, or a non-expansion template argument, deduction fails if
the argument itself is a pack expansion (C++0x
[temp.deduct.type]p22).
llvm-svn: 123279
|
|
|
|
|
|
| |
from James Widman.
llvm-svn: 123245
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 123237
|
|
|
|
|
|
|
|
|
| |
parameters it expanded to, map exactly the number of function
parameters that were expanded rather than just running to the end of
the instantiated parameter list. This finishes the implementation of
the last sentence of C++0x [temp.deduct.call]p1.
llvm-svn: 123213
|
|
|
|
|
|
|
|
|
| |
sentence of [temp.deduct.call]p1, both of which concern the
non-deducibility of parameter packs not at the end of a
parameter-type-list. The latter isn't fully implemented yet; see the
new FIXME.
llvm-svn: 123210
|
|
|
|
|
|
| |
appropritely when there are no other template arguments.
llvm-svn: 123204
|
|
|
|
|
|
|
|
| |
expression kinds. This is (indirectly) a test verifying that the
recursive AST visitor is visiting the children of these expression
nodes.
llvm-svn: 123198
|
|
|
|
|
|
|
|
|
| |
pack expansions in template argument lists and function parameter
lists. The implementation of this paragraph should be complete
*except* for cases where we're substituting into one of the unexpanded
packs in a pack expansion; that's a general issue I haven't solved yet.
llvm-svn: 123188
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
function class template.
llvm-svn: 123024
|
|
|
|
|
|
|
|
|
|
| |
tuple class template. This implementation is boosted directly from the
variadic templates proposal. N2080.
Note that one section is #ifdef'd out. I'll implement that aspect of
template argument deduction next.
llvm-svn: 123016
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instantiated function parameters, enabling instantiation of arbitrary
pack expansions involving function parameter packs. At this point, we
can now correctly compile a simple, variadic print() example:
#include <iostream>
#include <string>
void print() {}
template<typename Head, typename ...Tail>
void print(const Head &head, const Tail &...tail) {
std::cout << head;
print(tail...);
}
int main() {
std::string hello = "Hello";
print(hello, ", world!", " ", 2011, '\n');
}
llvm-svn: 123000
|
|
|
|
|
|
|
|
|
| |
parameters into parameter types, so that substitution of
explicitly-specified function template arguments uses the same
path. This enables the use of explicitly-specified function template
arguments with variadic templates.
llvm-svn: 122986
|
|
|
|
|
|
|
|
|
|
|
|
| |
template whose last parameter is a parameter pack. This allows us to
form a call to, e.g.,
template<typename ...Args1, typename ...Args2>
void f(std::pair<Args1, Args2> ...pairs);
given zero or more instances of "pair".
llvm-svn: 122973
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Declaration of function parameter packs
2) Instantiation of function parameter packs within function types.
3) Template argument deduction of function parameter packs when
matching two function types.
We're missing all of the important template-instantiation logic for
function template definitions, along with template argument deduction
from the argument list of a function call, so don't even think of
trying to use these for real yet.
llvm-svn: 122926
|
|
|
|
|
|
|
| |
corresponding template parameter, make sure that prior converted
template arguments are available for substitution.
llvm-svn: 122902
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|