| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
-Wint-to-pointer-cast.
llvm-svn: 123719
|
| |
|
|
| |
llvm-svn: 123667
|
| |
|
|
|
|
|
| |
This allows us to cache a "#pragma unused" that occurs inside an inline C++ member function.
Fixes rdar://8829590&8770988.
llvm-svn: 123666
|
| |
|
|
|
|
|
| |
Enforce C++[class.mem]p8:
A virt-specifier-seq shall contain at most one of each virt-specifier.
llvm-svn: 123611
|
| |
|
|
|
|
| |
base or member initializers as noreturn.
llvm-svn: 123603
|
| |
|
|
|
|
| |
C++ code
llvm-svn: 123582
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
-Wuninitialized based on CFG dataflow analysis. WIP.
llvm-svn: 123512
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Remove this variable (found by clang static analyzer).
llvm-svn: 123484
|
| |
|
|
|
|
| |
used; nuke all assignments and its declaration.
llvm-svn: 123483
|
| |
|
|
| |
llvm-svn: 123482
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
switch() statements.
llvm-svn: 123429
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
bunch of duplicated checks for parameter pack/non-pack mismatches.
llvm-svn: 123343
|
| |
|
|
|
|
|
| |
(static_cast, dynamic_cast, reinterpret_cast, or const_cast) to
improve source-location information. Fixes PR8960.
llvm-svn: 123336
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Slight optimization of getObjCGCAttrKind.
llvm-svn: 123295
|
| |
|
|
| |
llvm-svn: 123291
|
| |
|
|
|
|
|
| |
in ASTContext-allocated memory, copying the provided template
arguments. Use this new routine where we can. No functionality change.
llvm-svn: 123289
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 123236
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LL or i64 suffix is used. This MSVC behavior.
For example:
void f(long long){ printf("long long"); }
void f(unsigned long long) { printf("unsigned long long"); }
int main() {
f(0xffffffffffffffffLL);
}
Will print "long long" using MSVC.
This patch also fixes 16 compile errors related to overloading issues when parsing the MSVC 2008 C++ standard lib.
llvm-svn: 123231
|
| |
|
|
|
|
|
| |
complete. However, if it returns a reference type, don't require the
type it refers to to be complete. Fixes <rdar://problem/8807070>.
llvm-svn: 123214
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
argument packs from a set of deduced arguments, then checks that those
argument packs match previously-deduced argument packs.
llvm-svn: 123182
|
| |
|
|
|
|
|
| |
template argument packs. This also ensures that explicitly-specified
template arguments get properly represented in those cases.
llvm-svn: 123180
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
more accurate, and makes it make sense for it to hold a delegating constructor
call.
llvm-svn: 123084
|
| |
|
|
| |
llvm-svn: 123076
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
temporaries with no-return destructors. The CFG now properly supports
temporaries and implicit destructors which both makes this kludge no
longer work, and conveniently removes the need for it.
Turn on CFG handling of implicit destructors and initializers. Several
ad-hoc benchmarks don't indicate any measurable performance impact from
growing the CFG, and it fixes real correctness problems with warnings.
As a result of turning on these CFG elements, we started to tickle an
inf-loop in the unreachable code logic used for warnings. The fix is
trivial.
llvm-svn: 123056
|
| |
|
|
|
|
|
| |
prefix in a printf format string is matched
with the appropriate conversion specifier.
llvm-svn: 123055
|
| |
|
|
|
|
|
| |
TreeTransform version of TransformExprs() rather than explicit loop,
so that we expand pack expansions properly. Test cast coming soon...
llvm-svn: 123014
|
| |
|
|
|
|
| |
function parameter pack expansions.
llvm-svn: 123007
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 122942
|