| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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 packs when finishing template argument deduction for a function template
llvm-svn: 122843
|
|
|
|
|
|
|
| |
non-type template parameter pack, make sure to create a pack expansion
for the corresponding template argument.
llvm-svn: 122799
|
|
|
|
|
|
|
| |
initialize those lovely mixins that come from pack expansions of base
specifiers.
llvm-svn: 122793
|
|
|
|
| |
llvm-svn: 122782
|
|
|
|
| |
llvm-svn: 122780
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
expression lists.
llvm-svn: 122764
|
|
|
|
| |
llvm-svn: 122752
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template argument (described by an expression, of course). For
example:
template<int...> struct int_tuple { };
template<int ...Values>
struct square {
typedef int_tuple<(Values*Values)...> type;
};
It also lays the foundation for pack expansions in an initializer-list.
llvm-svn: 122751
|
|
|
|
|
|
| |
file
llvm-svn: 122748
|
|
|
|
|
|
|
|
| |
caused an assertion when dealing with non-type template parameter
packs. Add some tests for deduction and instantiation of non-type
template parameter packs.
llvm-svn: 122534
|
|
|
|
| |
llvm-svn: 122533
|
|
|
|
|
|
|
|
| |
extract the appropriate argument from the argument pack (based on the
current substitution index, of course). Simple instantiation of pack
expansions involving non-type template parameter packs now works.
llvm-svn: 122532
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
template argument corresponding to a template parameter pack is an
argument pack of a pack expansion of that template parameter
pack. Implements C++0x [temp.dep.type]p2 (at least, as much of it as
we can).
llvm-svn: 122498
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameter packs. In particular, a parameter pack not otherwise deduced
is deduced to an empty parameter pack.
The C++0x wording here is a bit unfortunate; this should really only
apply to function templates, and it mentions "trailing" parameter
packs, which doesn't really make sense in the context of function
templates. Will file a core issue separately.
llvm-svn: 122463
|
|
|
|
|
|
|
|
| |
the presence of a pack expansion anywhere except at the end of a
template-argument-list causes the entire template-argument-list to be
a non-deduced context.
llvm-svn: 122461
|
|
|
|
|
|
|
|
|
| |
single routine. Extend that routine to handle consistency
checking for template argument packs, so that we can compare the
deduced packs for template parameter packs across different pack
expansions.
llvm-svn: 122452
|
|
|
|
|
|
|
|
|
|
|
| |
pattern is a template argument, which involves repeatedly deducing
template arguments using the pattern of the pack expansion, then
bundling the resulting deductions into an argument pack.
We can now handle a variety of simple list-handling metaprograms using
variadic templates. See, e.g., the new "count" metaprogram.
llvm-svn: 122439
|
|
|
|
|
|
|
|
|
|
| |
dependent template specialization type, the number of template
arguments need not match precisely. Rather than checking the number of
arguments eagerly (which does not consider argument packs), let the
deduction routine for template argument lists cope with too many/too
few arguments.
llvm-svn: 122425
|
|
|
|
|
|
|
|
|
|
|
|
| |
deduction. Unify all of the looping over template arguments for
deduction purposes into a single place, where argument pack expansion
occurs; this is also the hook for deducing from pack expansions, which
itself is not yet implemented.
For now, at least we can handle a basic "count" metafunction written
with variadics. See the new test for the formulation that works.
llvm-svn: 122418
|
|
|
|
|
|
| |
being friends
llvm-svn: 122335
|
|
|
|
|
|
| |
in an exception specification.
llvm-svn: 122297
|
|
|
|
|
|
|
| |
specifications. We can't yet instantiate them, however, since I
tripped over PR8835.
llvm-svn: 122292
|
|
|
|
|
|
| |
in a nested-name-specifier
llvm-svn: 122282
|
|
|
|
|
|
| |
getting extra "<>" delimiters around template argument packs.
llvm-svn: 122280
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
occur within statements. Teach Sema::ActOnExceptionDeclarator() to
check for unexpanded parameter packs in the exception type.
llvm-svn: 121984
|
|
|
|
| |
llvm-svn: 121964
|
|
|
|
| |
llvm-svn: 121962
|
|
|
|
| |
llvm-svn: 121938
|
|
|
|
| |
llvm-svn: 121934
|
|
|
|
|
|
|
| |
drive-by, make sure to check for unexpanded parameter packs within the
name of a declaration.
llvm-svn: 121930
|
|
|
|
| |
llvm-svn: 121928
|
|
|
|
| |
llvm-svn: 121922
|
|
|
|
|
|
|
|
| |
declarations. This is a work in progress, as I go through the C++
declaration grammar to identify where unexpanded parameter packs can
occur.
llvm-svn: 121912
|
|
|
|
|
|
|
| |
unexpanded parameter pack" bit and that the recursive AST visitor can
then find those unexpanded parameter packs.
llvm-svn: 121899
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameter packs within a statement, type, etc. Use this visitor to
provide improved diagnostics for the presence of unexpanded parameter
packs in a full expression, base type, declaration type, etc., by
highlighting the unexpanded parameter packs and providing their names,
e.g.,
test/CXX/temp/temp.decls/temp.variadic/p5.cpp:28:85: error: declaration type
contains unexpanded parameter packs 'VeryInnerTypes',
'OuterTypes', ...
...VeryInnerTypes, OuterTypes>, pair<InnerTypes, OuterTypes> > types;
~~~~~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~~~ ^
llvm-svn: 121883
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|