| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
In passing, add 'concept' to the list of template kinds in diagnostics.
llvm-svn: 330890
|
| |
|
|
|
|
|
|
|
| |
diagnostics.
We were previouly assuming that every type template was a class template, which
is not true any more.
llvm-svn: 291988
|
| |
|
|
|
|
|
|
|
|
|
| |
deduction in partial ordering.
This prevents us from crashing due to attempting to instantiate the same class
template specialization definition multiple times. (Debug builds also appear to
sometimes hit the stack limit before hitting the instantiation depth limit in
this case.)
llvm-svn: 291407
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
corresponding arguments are unexpanded pack expansions, we can compute the
result without substituting them. This significantly improves the memory usage
and performance of make_integer_sequence implementations that do this kind of
thing:
using result = integer_sequence<T, Ns ..., sizeof...(Ns) + Ns ...>;
... but note that such an implementation will still perform O(sizeof...(Ns)^2)
work while building the second pack expansion (we just have a somewhat lower
constant now).
In principle we could get this down to linear time by caching whether the
number of expansions of a pack is constant, or checking whether we're within an
alias template before scanning the pack for pack expansions (since that's the
only case in which we do substitutions within a dependent context at the
moment), but this patch doesn't attempt that.
llvm-svn: 284653
|
| |
|
|
|
|
|
|
| |
they're redeclarations. This is necessary in order for name lookup to correctly
find the most recent declaration of the name (which affects default template
argument lookup and cross-module merging, among other things).
llvm-svn: 275612
|
| |
|
|
|
|
|
| |
This doesn't quite get alias template equivalence right yet, but handles the
egregious cases where we would silently give the wrong answers.
llvm-svn: 248431
|
| |
|
|
|
|
|
|
|
|
| |
When we are parsing a type for an alias template, we are not entering
the context, so we can't look into dependent classes. Make sure the
parser handles this correctly.
PR16904.
llvm-svn: 188510
|
| |
|
|
|
|
|
|
| |
templates and explicit specializations
This patch essentially removes all the FIXMEs following calls to DeduceTemplateArguments() that want to keep track of deduction failure info.
llvm-svn: 186730
|
| |
|
|
|
|
|
| |
Make sure we correctly expand packs which expand to another
pack in a function type.
llvm-svn: 186728
|
| |
|
|
|
|
|
|
|
|
| |
When we see a pack, and replace it with a template argument which is
also a pack, we want to use the pack pattern, not the expanded pack.
The caller should take care of expanding the pack afterwards.
Fixes PR16646.
llvm-svn: 186713
|
| |
|
|
|
|
|
| |
pattern might be an alias template which doesn't use its arguments). It's always
instantiation-dependent, though.
llvm-svn: 160246
|
| |
|
|
|
|
|
|
|
| |
being a property of a canonical type to being a property of the fully-sugared
type. This should only make a difference in the case where an alias template
ignores one of its parameters, and that parameter is an unexpanded parameter
pack.
llvm-svn: 160244
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* When substituting a reference to a non-type template parameter pack where the
corresponding argument is a pack expansion, transform into an expression
which contains an unexpanded parameter pack rather than into an expression
which contains a pack expansion. This causes the SubstNonTypeTemplateParmExpr
to be inside the PackExpansionExpr, rather than outside, so the expression
still looks like a pack expansion and can be deduced.
* Teach MarkUsedTemplateParameters that we can deduce a reference to a template
parameter if it's wrapped in a SubstNonTypeTemplateParmExpr (such nodes are
added during alias template substitution).
llvm-svn: 159922
|
| |
|
|
|
|
|
|
| |
expression, skip over any SubstNonTypeTemplateParmExprs which alias templates
may have inserted before checking for a DeclRefExpr referring to a non-type
template parameter declaration.
llvm-svn: 159909
|
| |
|
|
|
|
|
| |
get a function parameter pack (but don't due to weird substitutions),
complain. Fixes the last bit of PR11848.
llvm-svn: 148960
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
iff its substitution contains an unexpanded parameter pack. This has the effect
that we now reject declarations such as this (which we used to crash when
expanding):
template<typename T> using Int = int;
template<typename ...Ts> void f(Int<Ts> ...ints);
The standard is inconsistent on how this case should be treated.
llvm-svn: 148905
|
| |
|
|
|
|
| |
-std=c++0x. Patch by Ahmed Charles!
llvm-svn: 141900
|
|
|
the right order.
Also, don't reject alias templates in all ElaboratedTypes: some ElaboratedTypes do not correspond to elaborated-type-specifiers.
llvm-svn: 131342
|
