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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123448 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123425 91177308-0d34-0410-b5e6-96231b3b80d8
another pack expansion type. This can happen when rebuilding types in
the current instantiation.
Fixes <rdar://problem/8848837> (Clang crashing on libc++ <functional>).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123316 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123279 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123188 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123163 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122986 91177308-0d34-0410-b5e6-96231b3b80d8
The initial TreeTransform is a cop-out, but it's more-or-less equivalent
to what we were doing before, or rather what we're doing now and might
eventually stop doing in favor of using this type.
I am simultaneously intrigued by the possibilities of rebuilding a
dependent Attri
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122942 91177308-0d34-0410-b5e6-96231b3b80d8
TypeSourceInfo when transforming a function parameter. The callees of
this routine already assume that TypeSourceInfo will be present, and
we want to always be sure that it exists.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122927 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122926 91177308-0d34-0410-b5e6-96231b3b80d8
for template template argument pack expansions (which was no longer
used) and another that was a placeholder for an llvm_unreachable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122898 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122896 91177308-0d34-0410-b5e6-96231b3b80d8
the declaration-specifiers and on the declarator itself are moved
to the appropriate declarator chunk. This permits a greatly
simplified model for how to apply these attributes, as well as
allowing a much more efficient query for the GC attribute.
Now all qualifier queries follow the same basic strategy of
"local qualifiers, local qualifiers on the canonical type,
then look through arrays". This can be easily optimized by
changing the canonical qualified-array-type representation.
Do not process type attributes as decl attributes on declarations
with declarators.
When computing the type of a block, synthesize a prototype
function declarator chunk if the decl-spec type was not a
function. This simplifies the logic for building block signatures.
Change the logic which inserts an objc_read_weak on a block
literal to only fire if the block has a __weak __block variable,
rather than if the return type of the block is __weak qualified,
which is not actually a sensible thing to ask.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122871 91177308-0d34-0410-b5e6-96231b3b80d8
parameter pack.
Note that we're missing proper libclang support for the new
SizeOfPackExpr expression node.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122813 91177308-0d34-0410-b5e6-96231b3b80d8
argument. As part of this, be more careful when determining if there
are any parameter packs that cannot be expanded.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122776 91177308-0d34-0410-b5e6-96231b3b80d8
(transforming each in turn) into calls into one central routine
(TransformExprs) that transforms a list of expressions. This
refactoring is preparatory work for pack expansions whose in an
expression-list.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122761 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122751 91177308-0d34-0410-b5e6-96231b3b80d8
lists, so that all such transformations go through a single,
iterator-based transformation function. This is the only place where
we need to implement the logic for transforming pack expansions whose
pattern is a template argument.
Unfortunately, the new cases this refactoring brings into the fold
can't be meaningfully tested yet. We need template argument deduction
to work well enough for variadic function templates first.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122289 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122278 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122223 91177308-0d34-0410-b5e6-96231b3b80d8
and use a better and more general approach, where NullStmt has a flag to indicate whether it was preceded by an empty macro.
Thanks to Abramo Bagnara for the hint!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119887 91177308-0d34-0410-b5e6-96231b3b80d8
store it on the expression node. Also store an "object kind",
which distinguishes ordinary "addressed" l-values (like
variable references and pointer dereferences) and bitfield,
@property, and vector-component l-values.
Currently we're not using these for much, but I aim to switch
pretty much everything calculating l-valueness over to them.
For now they shouldn't necessarily be trusted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119685 91177308-0d34-0410-b5e6-96231b3b80d8
certain internal type-checking procedures as well as for representing
certain implicitly-generated operations. Uses to follow.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119289 91177308-0d34-0410-b5e6-96231b3b80d8
parameters to the Transform*Type functions and instead call out
the specific cases where an object type and the unqualified lookup
results are important. Fixes an assert and failed compile on
a testcase from PR7248.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118887 91177308-0d34-0410-b5e6-96231b3b80d8
NEON vector types need to be mangled in a special way to comply with ARM's ABI,
similar to some of the AltiVec-specific vector types. This patch is mostly
just renaming a bunch of "AltiVecSpecific" things, since they will no longer
be specific to AltiVec. Besides that, it just adds the new "NeonVector" enum.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118724 91177308-0d34-0410-b5e6-96231b3b80d8
abstractions (e.g., TemplateArgumentListBuilder) that were designed to
support variadic templates. Only a few remnants of variadic templates
remain, in the parser (parsing template type parameter packs), AST
(template type parameter pack bits and TemplateArgument::Pack), and
Sema; these are expected to be used in a future implementation of
variadic templates.
But don't get too excited about that happening now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118385 91177308-0d34-0410-b5e6-96231b3b80d8
This adds them where missing, and traces them through PCH. We fix at least one
bug in the extents found by the Index library, and make a lot of refactoring
tools which care about the exact formulation of a constructor call easier to
write. Also some minor cleanups to more consistently follow the friend pattern
instead of the setter pattern when rebuilding a serialized AST.
Patch originally by Samuel Benzaquen.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117254 91177308-0d34-0410-b5e6-96231b3b80d8
i.e. expressions with an internally-convenient type which should not be
appearing in generally valid, complete ASTs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116281 91177308-0d34-0410-b5e6-96231b3b80d8
arguments in either the placement or constructor arguments. This is
important if the default arguments refer to a declaration or create a
temporary.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@115700 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor
John McCall
Matt Beaumont-Gay
Argyrios Kyrtzidis
Abramo Bagnara
Francois Pichet
Bob Wilson
Chandler Carruth
Fariborz Jahanian