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
* 'auto' was being rejected on abstract-declarators with trailing return
types and on typedefs with trailing return types. 'auto' is always
allowed in these cases. This was found while testing the fix for PR 9278.
* A very poor diagnostic was being issued for auto (f() -> int): "return
type must be 'auto', not 'auto'". This is closely related to PR 9060.
* Trailing return type handling was happening slightly too late,
resulting in the checks for functions returning arrays and functions
returning functions being missed.
llvm-svn: 126166
This actually rules out too much, since it also catches typedefs for pointers to functions with trailing return types:
typedef auto (*F)() -> int;
Fix for that (and the same issue in all abstract-declarators) to follow shortly.
llvm-svn: 126153
* Flag indicating 'we're parsing this auto typed variable's initializer' moved from VarDecl to Sema
* Temporary template parameter list for auto deduction is now allocated on the stack.
* Deduced 'auto' types are now uniqued.
llvm-svn: 126139
includes explicitly-specified template arguments) to a function
template specialization in cases where no deduction is performed or
deduction fails. Patch by Faisal Vali, fixes PR7505!
llvm-svn: 126048
a scoped enumeration type to an integral or floating type,
properly. There was an over-eager assertion, and it was missing the
floating-point case.
Fixes PR9107/<rdar://problem/8937402>.
llvm-svn: 125825
LabelDecl and LabelStmt. There is a 1-1 correspondence between the
two, but this simplifies a bunch of code by itself. This is because
labels are the only place where we previously had references to random
other statements, causing grief for AST serialization and other stuff.
This does cause one regression (attr(unused) doesn't silence unused
label warnings) which I'll address next.
This does fix some minor bugs:
1. "The only valid attribute " diagnostic was capitalized.
2. Various diagnostics printed as ''labelname'' instead of 'labelname'
3. This reduces duplication of label checking between functions and blocks.
Review appreciated, particularly for the cindex and template bits.
llvm-svn: 125733
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
the parser will complete the declarator with a valid decl and thus trigger
delayed diagnostics for it. It certainly looks like we were intentionally
returning null here, but I couldn't find any good reason for it, and there
wasn't a comment, so farewell to all that.
llvm-svn: 125556
access-control diagnostics which arise from the portion of the declarator
following the scope specifier, just in case access is granted by
friending the individual method. This can also happen with in-line
member function declarations of class templates due to templated-scope
friend declarations.
We were really playing fast-and-loose before with this sort of thing,
and it turned out to work because *most* friend functions are in file
scope. Making us delay regardless of context exposed several bugs with
how we were manipulating delay. I ended up needing a concept of a
context that's independent of the declarations in which it appears,
and then I actually had to make some things save contexts correctly,
but delay should be much cleaner now.
I also encapsulated all the delayed-diagnostics machinery in a single
subobject of Sema; this is a pattern we might want to consider rolling
out to other components of Sema.
llvm-svn: 125485
- BlockDeclRefExprs always store VarDecls
- BDREs no longer store copy expressions
- BlockDecls now store a list of captured variables, information about
how they're captured, and a copy expression if necessary
With that in hand, change IR generation to use the captures data in
blocks instead of walking the block independently.
Additionally, optimize block layout by emitting fields in descending
alignment order, with a heuristic for filling in words when alignment
of the end of the block header is insufficient for the most aligned
field.
llvm-svn: 125005
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
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
overload a function without a ref-qualifier (C++0x
[over.load]p2). This, apparently, completes the implementation of
rvalue references for *this.
llvm-svn: 124321
reference binding is for the implicit object parameter of a member
function with a ref-qualifier. My previous comment, that we didn't
need to track this explicitly, was wrong: we do in fact get
rvalue-references-prefer-rvalues overloading with ref-qualifiers.
llvm-svn: 124313
the presence and form of a ref-qualifier. Note that we do *not* yet
implement the restriction in C++0x [over.load]p2 that requires either
all non-static functions with a given parameter-type-list to have a
ref-qualifier or none of them to have a ref-qualifier.
llvm-svn: 124297
- Add ref-qualifiers to the type system; they are part of the
canonical type. Print & profile ref-qualifiers
- Translate the ref-qualifier from the Declarator chunk for
functions to the function type.
- Diagnose mis-uses of ref-qualifiers w.r.t. static member
functions, free functions, constructors, destructors, etc.
- Add serialization and deserialization of ref-qualifiers.
llvm-svn: 124281
for reference binding (C++ [over.rank.ics]p3b1sb4), so that we prefer
the binding of an lvalue reference to a function lvalue over the
binding of an rvalue reference. This change resolves the ambiguity
with std::forward and lvalue references to function types in a way
that seems consistent with the original rvalue references proposal.
My proposed wording for this change is shown in
isBetterReferenceBindingKind(); we'll try to get this change adopted
in the C++0x working paper as well.
llvm-svn: 124236
(C++0x [over.ics.rank]p3) when one binding is an lvalue reference and
the other is an rvalue reference that binds to an rvalue. In
particular, we were using the predict "is an rvalue reference" rather
than "is an rvalue reference that binds to an rvalue", which was
incorrect in the one case where an rvalue reference can bind to an
lvalue: function references.
This particular issue cropped up with std::forward, where Clang was
picking an std::forward overload while forwarding an (lvalue)
reference to a function. However (and unfortunately!), the right
answer for this code is that the call to std::forward is
ambiguous. Clang now gets that right, but we need to revisit the
std::forward implementation in libc++.
llvm-svn: 124216
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
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
when returning an NRVO candidate expression. For example, this
properly picks the move constructor when dealing with code such as
MoveOnlyType f() { MoveOnlyType mot; return mot; }
The previously-XFAIL'd rvalue-references test case now works, and has
been moved into the appropriate paragraph-specific test case.
llvm-svn: 123992
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
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
specification. In particular, an rvalue reference can bind to an
initializer expression that is an lvalue if the referent type and the
initializer expression type are not reference-related. This is a newer
formulation to the previous "rvalue references can never bind to
lvalues" rule.
llvm-svn: 123952
working paper's structure. The only functional change here is that we
now handling binding to array rvalues, which we would previously reject.
llvm-svn: 123918
involving rvalue references, to start scoping out what is and what
isn't implemented. In the process, tweak some standards citations,
type desugaring, and teach the tentative parser about && in
ptr-operator.
llvm-svn: 123913
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
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
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
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
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
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
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
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
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
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
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
declaration name of the array when present. This ensures that
a poor-man's C++03 static_assert will include the user error message
often embedded in the name.
Update all the tests to reflect the new wording, and add a test for the
name behavior.
llvm-svn: 122802
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
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
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
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
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
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
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
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
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.
llvm-svn: 119685
particular, we only add the implement object parameter type if only
one of the function templates is a non-static member function
template.
Moreover, since this DR differs from existing practice in C++98/03,
this commit implements the existing practice (which ignores the
first parameter of the function template that is not the non-static
member function template) in C++98/03 mode.
llvm-svn: 119145
in the order they occur within the class template, delaying
out-of-line member template partial specializations until after the
class has been fully instantiated. This fixes a regression introduced
by r118454 (itself a fix for PR8001).
llvm-svn: 118704
only keep deduction results for successful deductions, so that they
can be compared against each other. Fixes PR8462, from Richard Smith!
llvm-svn: 117983
members in class subobjects of different types. So long as the
underlying declaration sets are the same, and the declaration sets
involve non-instance members, this is not an ambiguity.
llvm-svn: 117163
themselves have no template parameters. This is actually a restriction
due to the grammar of template template parameters, but we choose to
diagnose it in Sema to provide better recovery.
llvm-svn: 117032
redeclarations of main appropriately rather than allowing it to be
overloaded. Also, disallowing declaring main as a template.
Fixes GCC DejaGNU g++.old-deja/g++.other/main1.C.
llvm-svn: 117029
construct an unsupported friend when there's a friend with a templated
scope specifier. Fixes a consistency crash, rdar://problem/8540527
llvm-svn: 116786
John McCall