permits, among other things, ripping apart and reconstructing
templates via partial specialization:
template<typename T>
struct DeepRemoveConst { typedef T type; };
template<typename T>
struct DeepRemoveConst<const T> {
typedef typename DeepRemoveConst<T>::type type;
};
template<template<typename> class TT, typename T>
struct DeepRemoveConst<TT<T> > {
typedef TT<typename DeepRemoveConst<T>::type> type;
};
Also, fix a longstanding thinko in the code handling partial ordering
of class template partial specializations. We were performing the
second deduction without clearing out the results of the first
deduction. It's amazing we got through so much code with such a
horrendous error :(
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86893 91177308-0d34-0410-b5e6-96231b3b80d8
parameters. Rather than storing them as either declarations (for the
non-dependent case) or expressions (for the dependent case), we now
(always) store them as TemplateNames.
The primary change here is to add a new kind of TemplateArgument,
which stores a TemplateName. However, making that change ripples to
every switch on a TemplateArgument's kind, also affecting
TemplateArgumentLocInfo/TemplateArgumentLoc, default template
arguments for template template parameters, type-checking of template
template arguments, etc.
This change is light on testing. It should fix several pre-existing
problems with template template parameters, such as:
- the inability to use dependent template names as template template
arguments
- template template parameter default arguments cannot be
instantiation
However, there are enough pieces missing that more implementation is
required before we can adequately test template template parameters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86777 91177308-0d34-0410-b5e6-96231b3b80d8
types. Preserve it through template instantiation. Preserve it through PCH,
although TSTs themselves aren't serializable, so that's pretty much meaningless.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85500 91177308-0d34-0410-b5e6-96231b3b80d8
class template partial specializations of member templates. Also,
fixes a silly little bug in the marking of "used" template parameters
in member templates. Fixes PR5236.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85447 91177308-0d34-0410-b5e6-96231b3b80d8
but also remove some methods that cause ambiguities, and generally
make CanQual<blah> more analogous to QualType.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84976 91177308-0d34-0410-b5e6-96231b3b80d8
type is a template-id (e.g., basic_ostream<CharT, Traits>) and the
argument type is a class that has a derived class matching the
parameter type. Previously, we were giving up on template argument
deduction too early.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83177 91177308-0d34-0410-b5e6-96231b3b80d8
member functions of class template specializations, and static data
members. The mechanics are (mostly) present, but the semantic analysis
is very weak.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82789 91177308-0d34-0410-b5e6-96231b3b80d8
first implementation recognizes when a function declaration is an
explicit function template specialization (based on the presence of a
template<> header), performs template argument deduction + ambiguity
resolution to determine which template is being specialized, and hooks
There are many caveats here:
- We completely and totally drop any explicitly-specified template
arguments on the floor
- We don't diagnose any of the extra semantic things that we should
diagnose.
- I haven't looked to see that we're getting the right linkage for
explicit specializations
On a happy note, this silences a bunch of errors that show up in
libstdc++'s <iostream>, although Clang still can't get through the
entire header.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82728 91177308-0d34-0410-b5e6-96231b3b80d8
Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our
use of qualifiers and fix a few places that weren't dealing with qualifiers
quite right; many more remain.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82705 91177308-0d34-0410-b5e6-96231b3b80d8
Several of the existing methods were identical to their respective
specializations, and so have been removed entirely. Several more 'leaf'
optimizations were introduced.
The getAsFoo() methods which imposed extra conditions, like
getAsObjCInterfacePointerType(), have been left in place.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82501 91177308-0d34-0410-b5e6-96231b3b80d8
template smarter, by taking into account which function template
parameters are deducible from the call arguments. For example,
template<typename RandomAccessIterator>
void sort(RandomAccessIterator first, RandomAccessIterator last);
will have a code-completion string like
sort({RandomAccessIterator first}, {RandomAccessIterator last})
since the template argument for its template parameter is
deducible. On the other hand,
template<class X, class Y>
X* dyn_cast(Y *Val);
will have a code-completion string like
dyn_cast<{class X}>({Y *Val})
since the template type parameter X is not deducible from the function
call.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82306 91177308-0d34-0410-b5e6-96231b3b80d8
MarkUsedTemplateParameters, which is able to mark template parameters
used within non-deduced contexts as well as deduced contexts. Use this
to finish the implementation of [temp.deduct.partial]p11.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81794 91177308-0d34-0410-b5e6-96231b3b80d8
argument deduction. This fixes the new test case (since partial
ordering does not have a "verify the results of deduction" step), and
will allow failed template argument deductions to return more quickly
for, e.g., matching class template partial specializations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81779 91177308-0d34-0410-b5e6-96231b3b80d8
to a multi-level template argument list by making it explicit. The
forced auditing of callers found a bug in the instantiation of member
classes inside member templates.
I *love* static type systems.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80391 91177308-0d34-0410-b5e6-96231b3b80d8
template argument deduction from a conversion function (C++
[temp.deduct.conv]) with implicit conversions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79693 91177308-0d34-0410-b5e6-96231b3b80d8
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsRecordType() -> Type::getAs<RecordType>()
Type::getAsPointerType() -> Type::getAs<PointerType>()
Type::getAsBlockPointerType() -> Type::getAs<BlockPointerType>()
Type::getAsLValueReferenceType() -> Type::getAs<LValueReferenceType>()
Type::getAsRValueReferenceType() -> Type::getAs<RValueReferenceType>()
Type::getAsMemberPointerType() -> Type::getAs<MemberPointerType>()
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsTagType() -> Type::getAs<TagType>()
And remove Type::getAsReferenceType(), etc.
This change is similar to one I made a couple weeks ago, but that was partly
reverted pending some additional design discussion. With Doug's pending smart
pointer changes for Types, it seemed natural to take this approach.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77510 91177308-0d34-0410-b5e6-96231b3b80d8
real. It turns out that we need to actually move all of the qualifiers
up to the array type itself, then recanonicalize the deduced template
argument type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76788 91177308-0d34-0410-b5e6-96231b3b80d8
until Doug Gregor's Type smart pointer code lands (or more discussion occurs).
These methods just call the new Type::getAs<XXX> methods, so we still have
reduced implementation redundancy. Having explicit getAsXXXType() methods makes
it easier to set breakpoints in the debugger.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76193 91177308-0d34-0410-b5e6-96231b3b80d8
This method is intended to eventually replace the individual
Type::getAsXXXType<> methods.
The motivation behind this change is twofold:
1) Reduce redundant implementations of Type::getAsXXXType() methods. Most of
them are basically copy-and-paste.
2) By centralizing the implementation of the getAs<Type> logic we can more
smoothly move over to Doug Gregor's proposed canonical type smart pointer
scheme.
Along with this patch:
a) Removed 'Type::getAsPointerType()'; now clients use getAs<PointerType>.
b) Removed 'Type::getAsBlockPointerTypE()'; now clients use getAs<BlockPointerType>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76098 91177308-0d34-0410-b5e6-96231b3b80d8
function template. Most of the change here is in factoring out the
common bits used for template argument deduction from a function call
and when taking the address of a function template.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@75044 91177308-0d34-0410-b5e6-96231b3b80d8
implement C++ [temp.deduct.call]p3b3, which allows a template-id
parameter to match a derived class of the argument, while deducing
template arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74965 91177308-0d34-0410-b5e6-96231b3b80d8
by distinguishing between substitution that occurs for template
argument deduction vs. explicitly-specifiad template arguments. This
is used both to improve diagnostics and to make sure we only provide
SFINAE in those cases where SFINAE should apply.
In addition, deal with the sticky issue where SFINAE only considers
substitution of template arguments into the *type* of a function
template; we need to issue hard errors beyond this point, as
test/SemaTemplate/operator-template.cpp illustrates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74651 91177308-0d34-0410-b5e6-96231b3b80d8
substitute those template arguments into the function parameter types
prior to template argument deduction. There's still a bit of work to
do to make this work properly when only some of the template arguments
are specified.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74576 91177308-0d34-0410-b5e6-96231b3b80d8
redundant, implicit instantiations of function templates and provide a
place where we can hang function template specializations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74454 91177308-0d34-0410-b5e6-96231b3b80d8
deduction using a base class of the argument type. No actual
functionality change; this is just a hook.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74356 91177308-0d34-0410-b5e6-96231b3b80d8
deduction from pointer and pointer-to-member types to work even in the
presence of a qualification conversion (C++ [temp.deduct.type]p3
bullet 2).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74354 91177308-0d34-0410-b5e6-96231b3b80d8
non-dependent parameter types. Instead, class template partial
specializations perform a final check of all of the instantiated
arguments. This model is cleaner, and works better for function
templates where the "final check" occurs during overload resolution.
Also, cope with cv-qualifiers when the parameter type was originally a
reference type, so that the deduced argument can be more qualified
than the transformed argument.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74323 91177308-0d34-0410-b5e6-96231b3b80d8
For a FunctionDecl that has been instantiated due to template argument
deduction, we now store the primary template from which it was
instantiated and the deduced template arguments. From this
information, we can instantiate the body of the function template.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74232 91177308-0d34-0410-b5e6-96231b3b80d8
templates.
For example, this now type-checks (but does not instantiate the body
of deref<int>):
template<typename T> T& deref(T* t) { return *t; }
void test(int *ip) {
int &ir = deref(ip);
}
Specific changes/additions:
* Template argument deduction from a call to a function template.
* Instantiation of a function template specializations (just the
declarations) from the template arguments deduced from a call.
* FunctionTemplateDecls are stored directly in declaration contexts
and found via name lookup (all forms), rather than finding the
FunctionDecl and then realizing it is a template. This is
responsible for most of the churn, since some of the core
declaration matching and lookup code assumes that all functions are
FunctionDecls.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74213 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor
John McCall
Sebastian Redl
Mike Stump
Anders Carlsson
Ted Kremenek
Steve Naroff
Argyrios Kyrtzidis