| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
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
|
