maintains a stack of evaluation contexts rather than having the parser
do it. This change made it simpler to track in which contexts
temporaries were created, so that we could...
"Forget" about temporaries created within unevaluated contexts, so
that we don't build a CXXExprWithTemporaries and, therefore, destroy
the integral-constness of our expressions. Fixes PR5609.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89908 91177308-0d34-0410-b5e6-96231b3b80d8
the linkage of a declaration. Switch the lame (and completely wrong)
NamedDecl::hasLinkage() over to using the new NamedDecl::getLinkage(),
along with the "can this declaration be a template argument?" check
that started all of this.
Fixes -fsyntax-only for PR5597.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89891 91177308-0d34-0410-b5e6-96231b3b80d8
of the current instantiation and members of an unknown specialization
when type-checking a qualified-if expression.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89653 91177308-0d34-0410-b5e6-96231b3b80d8
complaint to a warning and providing a helpful node in the case where
the "template<>" header is redundant because the corresponding
template-id refers to an explicit specialization. C++0x might still
change this behavior, and existing practice is all over the place on
the number of "template<>" headers actually needed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89651 91177308-0d34-0410-b5e6-96231b3b80d8
than tweaking existing ASTs, since we were (*gasp*) stomping on ASTs
within templates. I'm glad we found this little stick of TNT early...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89475 91177308-0d34-0410-b5e6-96231b3b80d8
A::f
that occurs within a non-static member function with a type-dependent
"this", don't consider this to be a case for introduction of an
implicit "(*this)." to refer to a specific member function unless we
know (at template definition time) that A is a base class of *this.
There is some disagreement here between GCC, EDG, and Clang about the
handling of this case. I believe that Clang now has the correct,
literal interpretation of the standard, but have asked for
clarification (c++std-core-15483).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89425 91177308-0d34-0410-b5e6-96231b3b80d8
rather than punting to a DependentSizedArrayType, tightening up our
type checking for template definitions. Thanks, John!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89407 91177308-0d34-0410-b5e6-96231b3b80d8
incomplete array initialization, where we have the following in a
template:
int a[] = { 1, 2, something-value-dependent };
// ...
sizeof(a);
The type of "a" appears to be a non-dependent IncompleteArrayType, but
treating it as such makes the sizeof(a) fail at template definition
time. We now correctly handle this by morphing the IncompleteArrayType
into a DependentSizedArrayType with a NULL expression, indicating that
its size has no corresponding expression (and, therefore, the type is
distinct from others).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89366 91177308-0d34-0410-b5e6-96231b3b80d8
Also, make the "don't know how to instantiate a particular kind of
declaration" diagnostic nicer, so we don't have to trap Clang in a
debugger to figure out what went wrong.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89050 91177308-0d34-0410-b5e6-96231b3b80d8
like a copy constructor to the overload set, just ignore it. This
ensures that we don't try to use such a constructor as a copy
constructor *without* triggering diagnostics at the point of
declaration.
Note that we *do* diagnose such copy constructors when explicitly
written by the user (e.g., as an explicit specialization).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@88733 91177308-0d34-0410-b5e6-96231b3b80d8
non-type template parameters or constants of pointer-to-member
type. Once checked, be sure to retain those pointer-to-member
constants as expressions if they are dependent, or as declarations if
they are not dependent.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@87010 91177308-0d34-0410-b5e6-96231b3b80d8
member type (e.g., T Class::*Member), build a pointer-to-member
constant expression. Previously, we we just building a simple
declaration reference expression, which meant that the expression was
not treated as a pointer to member.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@87000 91177308-0d34-0410-b5e6-96231b3b80d8
- Comparing template parameter lists to determine if we have a redeclaration
- Comparing template parameter lists to determine if we have equivalent
template template parameters
- Comparing template parameter lists to determine whether a template
template argument is valid for a given template template parameter.
Previously, we did not distinguish between the last two cases, which
got us into trouble when we were looking for exact type matches
between the types of non-type template parameters that were dependent
types. Now we do, so we properly delay checking of template template
arguments until instantiation time.
Also, fix an accidental fall-through in a case statement that was
causing crashes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86992 91177308-0d34-0410-b5e6-96231b3b80d8
template template parameter.
When building a template-id type, check whether the template-name
itself is dependent (even if the template arguments are not!) and
handle it as a template-id type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86913 91177308-0d34-0410-b5e6-96231b3b80d8
annotation token, because some of the tokens we're annotating might
not be in the set of cached tokens (we could have consumed them
unconditionally).
Also, move the tentative parsing from ParseTemplateTemplateArgument
into the one caller that needs it, improving recovery.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86904 91177308-0d34-0410-b5e6-96231b3b80d8
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
with its corresponding template parameter. This can happen when we
performed some substitution into the default template argument and
what we had doesn't match any more, e.g.,
template<int> struct A;
template<typename T, template<T> class X = A> class B;
B<long> b;
Previously, we'd emit a pretty but disembodied diagnostic showing how
the default argument didn't match the template parameter. The
diagnostic was good, but nothing tied it to the *use* of the default
argument in "B<long>". This commit fixes that.
Also, tweak the counting of active template instantiations to avoid
counting non-instantiation records, such as those we create for
(surprise!) checking default arguments, instantiating default
arguments, and performing substitutions as part of template argument
deduction.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86884 91177308-0d34-0410-b5e6-96231b3b80d8
template template parameter, substitute any prior template arguments
into the template template parameter. This, for example, allows us to
properly check the template template argument for a class such as:
template<typename T, template<T Value> class X> struct Foo;
The actual implementation of this feature was trivial; most of the
change is dedicated to giving decent diagnostics when this
substitution goes horribly wrong. We now get a note like:
note: while substituting prior template arguments into template
template parameter 'X' [with T = float]
As part of this change, enabled some very pedantic checking when
comparing template template parameter lists, which shook out a bug in
our overly-eager checking of default arguments of template template
parameters. We now perform only minimal checking of such default
arguments when they are initially parsed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86864 91177308-0d34-0410-b5e6-96231b3b80d8
nested-name-specifiers so that they don't gobble the template name (or
operator-function-id) unless there is also a
template-argument-list. For example, given
T::template apply
we would previously consume both "template" and "apply" as part of
parsing the nested-name-specifier, then error when we see that there
is no "<" starting a template argument list. Now, we parse such
constructs tentatively, and back off if the "<" is not present. This
allows us to parse dependent template names as one would use them for,
e.g., template template parameters:
template<typename T, template<class> class X = T::template apply>
struct MetaSomething;
Also, test default arguments for template template parameters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86841 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
templates. The instantiation of these default arguments must be (and
now, is) delayed until the template argument is actually used, at
which point we substitute all levels of template arguments
concurrently.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86578 91177308-0d34-0410-b5e6-96231b3b80d8
- 'for i in $(find . -type f); do sed -e 's#\(RUN:.*[^ ]\) *&& *$#\1#g' $i | FileUpdate $i; done', for the curious.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86430 91177308-0d34-0410-b5e6-96231b3b80d8
(without complaining if it fails) to get proper semantics: reference
binding with a derived-to-base conversion and the enumeration of
constructors for user-defined conversions. There are probably more
cases to fix, but my prior attempt at statically ensuring that
complete-type checking always happens failed. Perhaps I'll try again.
With this change, Clang can parse include/llvm/*.h!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86129 91177308-0d34-0410-b5e6-96231b3b80d8
still be dependent or invoke an overloaded operator. Previously, we
only supported builtin operators.
BinaryOperator/CompoundAssignOperator didn't have this issue because
we always built a CXXOperatorCallExpr node, even when name lookup
didn't find any functions to save until instantiation time. Now, that
code builds a BinaryOperator or CompoundAssignOperator rather than a
CXXOperatorCallExpr, to save some space.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86087 91177308-0d34-0410-b5e6-96231b3b80d8
type of the object even when it is dependent. Specifically, this makes
sure that we get the right type for "this->", which is important when
performing name lookup into this scope to determine whether an
identifier or operator-function-id is a template name.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86060 91177308-0d34-0410-b5e6-96231b3b80d8
expressions, keep track of whether we are immediately taking the
address of the expression. Pass this flag when building a declaration
name expression so that we handle pointer-to-member constants
properly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86017 91177308-0d34-0410-b5e6-96231b3b80d8
operators, e.g.,
operator+<int>
which now works in declarators, id-expressions, and member access
expressions. This commit only implements the non-dependent case, where
we can resolve the template-id to an actual declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85966 91177308-0d34-0410-b5e6-96231b3b80d8
representation of a C++ unqualified-id, along with a single parsing
function (Parser::ParseUnqualifiedId) that will parse all of the
various forms of unqualified-id in C++.
Replace the representation of the declarator name in Declarator with
the new UnqualifiedId class, simplifying declarator-id parsing
considerably and providing more source-location information to
Sema. In the future, I hope to migrate all of the other
unqualified-id-parsing code over to this single representation, then
begin to merge actions that are currently only different because we
didn't have a unqualified notion of the name in the parser.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85851 91177308-0d34-0410-b5e6-96231b3b80d8
integral constant expression, make sure to find where the initializer
was provided---inside or outside the class definition---since that can
affect whether we have an integral constant expression (and, we need
to see the initializer itself).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85741 91177308-0d34-0410-b5e6-96231b3b80d8
that is not known to be a base class at template definition time due
to some dependent base class. Treat qualified name lookup that refers
to a non-static data member or function as implicit class member
access when the "this" type would be dependent.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85718 91177308-0d34-0410-b5e6-96231b3b80d8
parameters and template type parameters, which occurs when
substituting into the declarations of member templates inside class
templates. This eliminates errors about our inability to "reduce
non-type template parameter depth", fixing PR5311.
Also fixes a bug when instantiating a template type parameter
declaration in a member template, where we weren't properly reducing
the template parameter's depth.
LLVM's StringSwitch header now parses.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85669 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation once we have committed to performing the
instantiation. As part of this, make our makeshift
template-instantiation location information suck slightly less.
Fixes PR5264.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85209 91177308-0d34-0410-b5e6-96231b3b80d8
so that we maintain better source information after template argument
deduction and overloading resolves down to a specific
declaration. Found and dealt with a few more cases that
FixOverloadedFunctionReference didn't cope with.
(Finally) added a test case that puts together this change with the
DeclRefExpr change to (optionally) include nested-name-specifiers and
explicit template argument lists.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84974 91177308-0d34-0410-b5e6-96231b3b80d8
qualified member access expression (e.g., t->U::member) when that
first qualifier refers to a template parameters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84612 91177308-0d34-0410-b5e6-96231b3b80d8
initialization if any of the constructor/initialization arguments are
type-dependent. Fixes PR5224.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84365 91177308-0d34-0410-b5e6-96231b3b80d8
CheckSpecializationInstantiationRedecl to check for
redeclarations/instantiations. Also fixes a longstanding issue where
our explicit-instantiation location information wasn't as good as it
could have been.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84216 91177308-0d34-0410-b5e6-96231b3b80d8
template, make sure to get the template that corresponds to *this*
declaration of the class template or specialization, rather than the
canonical specialization. Fixes PR5187.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84119 91177308-0d34-0410-b5e6-96231b3b80d8
to a member operator template. We missed updating this call site when
adding support for function templates; bug exposed by a test for
PR5072.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84111 91177308-0d34-0410-b5e6-96231b3b80d8
unknown type name, e.g.,
foo::bar x;
when "bar" does not refer to a type in "foo".
With this change, the parser now calls into the action to perform
diagnostics and can try to recover by substituting in an appropriate
type. For example, this allows us to easily diagnose some missing
"typename" specifiers, which we now do:
test/SemaCXX/unknown-type-name.cpp:29:1: error: missing 'typename'
prior to dependent type name 'A<T>::type'
A<T>::type A<T>::f() { return type(); }
^~~~~~~~~~
typename
Fixes PR3990.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84053 91177308-0d34-0410-b5e6-96231b3b80d8
what we found when we looked into <blah>", where <blah> is a
DeclContext*. We can now format DeclContext*'s in nice ways, e.g.,
"namespace N", "the global namespace", "'class Foo'".
This is part of PR3990, but we're not quite there yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84028 91177308-0d34-0410-b5e6-96231b3b80d8
function templates.
This commit ensures that friend function templates are constructed as
FunctionTemplateDecls rather than partial FunctionDecls (as they
previously were). It then implements template instantiation for friend
function templates, injecting the friend function template only when
no previous declaration exists at the time of instantiation.
Oh, and make sure that explicit specialization declarations are not
friends.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83970 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation has already been required. To do so, keep track of the
point of instantiation for anything that can be instantiated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83890 91177308-0d34-0410-b5e6-96231b3b80d8
injected-class-name (e.g., when we're referring to other
specializations of the current class template). Make sure that we see
the template rather than the injected-class-name. Fixes PR4768.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83672 91177308-0d34-0410-b5e6-96231b3b80d8
function of a class template was implicitly instantiated, explicitly
instantiated (declaration or definition), or explicitly
specialized. The same MemberSpecializationInfo structure will be used
for static data members and member classes as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83509 91177308-0d34-0410-b5e6-96231b3b80d8
templates. Previously, these weren't handled as specializations at
all. The AST for representing these as specializations is still a work
in progress.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83498 91177308-0d34-0410-b5e6-96231b3b80d8
declarations and explicit template instantiations, improving
diagnostics and making the code usable for function template
specializations (as well as class template specializations and partial
specializations).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83436 91177308-0d34-0410-b5e6-96231b3b80d8
explicit instantiation. Also, tighten up reference-count checking to
help catch these issues earlier. Fixes PR5069.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83225 91177308-0d34-0410-b5e6-96231b3b80d8
overload candidates (but not the built-in ones). We still rely on the
underlying built-in semantic analysis to produce the initial
diagnostic, then print the candidates following that diagnostic.
One side advantage of this approach is that we can perform more validation
of C++'s operator overloading with built-in candidates vs. the
semantic analysis for those built-in operators: when there are no
viable candidates, we know to expect an error from the built-in
operator handling code. Otherwise, we are not modeling the built-in
semantics properly within operator overloading. This is checked as:
assert(Result.isInvalid() &&
"C++ binary operator overloading is missing
candidates!");
if (Result.isInvalid())
PrintOverloadCandidates(CandidateSet, /*OnlyViable=*/false);
The assert() catches cases where we're wrong in a +Asserts build. The
"if" makes sure that, if this happens in a production clang
(-Asserts), we still build the proper built-in operator and continue
on our merry way. This is effectively what happened before this
change, but we've added the assert() to catch more flies.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83175 91177308-0d34-0410-b5e6-96231b3b80d8
specializations such as:
friend class std::vector<int>;
by using the same code path as explicit specializations, customized to
reference an existing ClassTemplateSpecializationDecl (or build a new
"undeclared" one).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82875 91177308-0d34-0410-b5e6-96231b3b80d8
class templates. We now treat friend class templates much more like
normal class templates, except that they still get special name lookup
rules. Fixes PR5057 and eliminates a bunch of spurious diagnostics in
<iostream>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82848 91177308-0d34-0410-b5e6-96231b3b80d8
template void f<int>(int);
~~~~~~
Previously, we silently dropped the template arguments. With this
change, we now use the template arguments (when available) as the
explicitly-specified template arguments used to aid template argument
deduction for explicit template instantiations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82806 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
value-dependent. Audit (and fixed) all calls to
Expr::isNullPointerConstant() to provide the correct behavior with
value-dependent expressions. Fixes PR5041 and a crash in libstdc++
<locale>.
In the same vein, properly compute value- and type-dependence for
ChooseExpr. Fixes PR4996.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82748 91177308-0d34-0410-b5e6-96231b3b80d8
complete (or, possibly causing template instantiation).
Test this via some explicit specializations of member functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82732 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
when we are not instantiating the corresponding "current
instantiation." This happens, e.g., when we are instantiating a
declaration reference that refers into the "current instantiation" but
occurs in a default function argument. The libstdc++ vector default
constructor now instantiates properly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82069 91177308-0d34-0410-b5e6-96231b3b80d8
point at the template and print out its template arguments, e.g.,
ambiguous-ovl-print.cpp:5:8: note: candidate function template specialization
[with T = int]
void f(T*, long);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81907 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation definition can follow an explicit instantiation
declaration. This is as far as I want to go with extern templates now,
but they will still need quite a bit more work to get all of the C++0x
semantics right.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81573 91177308-0d34-0410-b5e6-96231b3b80d8
- Diagnose attempts to add default arguments to templates (or member
functions of templates) after the initial declaration (DR217).
- Improve diagnostics when a default argument is redefined. Now, the
note will always point at the place where the default argument was
previously defined, rather than pointing to the most recent
declaration of the function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81548 91177308-0d34-0410-b5e6-96231b3b80d8
from its location. Initialize appropriately.
When implicitly creating a declaration of a class template specialization
after encountering the first reference to it, use the pattern class's
location instead of the location of the first reference.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81515 91177308-0d34-0410-b5e6-96231b3b80d8
partial specialization rather than a subclass of TemplateDecl. Fixes a
crash in libstdc++ 4.2's <map>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81407 91177308-0d34-0410-b5e6-96231b3b80d8
templates, e.g.,
x.template get<T>
We can now parse these, represent them within an UnresolvedMemberExpr
expression, then instantiate that expression node in simple cases.
This allows us to stumble through parsing LLVM's Casting.h.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81300 91177308-0d34-0410-b5e6-96231b3b80d8
Now that parsing, semantic analysis, and (I think) code generation of
pseudo-destructor expressions and explicit destructor calls works,
update the example-dynarray.cpp test to destroy the objects it
allocates and update the test to actually compile + link.
The code seems correct, but the Clang-compiled version dies with a
malloc error. Time to debug!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81025 91177308-0d34-0410-b5e6-96231b3b80d8
expressions, e.g.,
p->~T()
when p is a pointer to a scalar type.
We don't currently diagnose errors when pseudo-destructor expressions
are used in any way other than by forming a call.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81009 91177308-0d34-0410-b5e6-96231b3b80d8
things, this means that we can properly cope with member access
expressions such as
t->operator T()
where T is a template parameter (or other dependent type).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80957 91177308-0d34-0410-b5e6-96231b3b80d8
involve qualified names, e.g., x->Base::f. We now maintain enough
information in the AST to compare the results of the name lookup of
"Base" in the scope of the postfix-expression (determined at template
definition time) and in the type of the object expression.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80953 91177308-0d34-0410-b5e6-96231b3b80d8
with to properly support member access expressions in templates. This
test is XFAIL'd, because we get it completely wrong, but I've made the
minimal changes to the representation to at least avoid a crash.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80856 91177308-0d34-0410-b5e6-96231b3b80d8
x->Base::f
We no longer try to "enter" the context of the type that "x" points
to. Instead, we drag that object type through the parser and pass it
into the Sema routines that need to know how to perform lookup within
member access expressions.
We now implement most of the crazy name lookup rules in C++
[basic.lookup.classref] for non-templated code, including performing
lookup both in the context of the type referred to by the member
access and in the scope of the member access itself and then detecting
ambiguities when the two lookups collide (p1 and p4; p3 and p7 are
still TODO). This change also corrects our handling of name lookup
within template arguments of template-ids inside the
nested-name-specifier (p6; we used to look into the scope of the
object expression for them) and fixes PR4703.
I have disabled some tests that involve member access expressions
where the object expression has dependent type, because we don't yet
have the ability to describe dependent nested-name-specifiers starting
with an identifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80843 91177308-0d34-0410-b5e6-96231b3b80d8
simple-template-id form), check whether the scope specifier is
computable as a declaration context rather than checking whether it is
dependent, so that we properly cope with members of the current
instantiation.
Improve testing for typename specifiers that terminate in a
simpe-template-id.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80783 91177308-0d34-0410-b5e6-96231b3b80d8
work correctly.
The change in lib/AST/DeclCXX.cpp is mostly a large reindentation; I
couldn't figure out a good way to avoid it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80446 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
When performing template instantiation of the definitions of member
templates (or members thereof), we build a data structure containing
the template arguments from each "level" of template
instantiation. During template instantiation, we substitute all levels
of template arguments simultaneously.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80389 91177308-0d34-0410-b5e6-96231b3b80d8
MultiLevelTemplateArgumentList. This is a baby step toward
instantiating member templates; no intended functionality change yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80380 91177308-0d34-0410-b5e6-96231b3b80d8
templates within class templates, producing a member function template
of a class template specialization. If you can parse that, I'm
sorry. Example:
template<typename T>
struct X {
template<typename U> void f(T, U);
};
When we instantiate X<int>, we now instantiate the declaration
X<int>::f, which looks like this:
template<typename U> void X<int>::f(int, U);
The path this takes through
TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and
ugly, but I don't know how to improve it yet. I'm resting my hopes on
the multi-level substitution required to instantiate definitions of
nested templates, which may simplify this code as well.
More testing to come...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80252 91177308-0d34-0410-b5e6-96231b3b80d8
TypenameType if getTypeName is looking at a member of an unknown
specialization. This allows us to properly parse class templates that
derived from type that could only otherwise be described by a typename type,
e.g.,
template<class T> struct X {};
template<typename T> struct Y : public X<T>::X { };
Fixes PR4381.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80123 91177308-0d34-0410-b5e6-96231b3b80d8
qualified name does not actually refer into a class/class
template/class template partial specialization.
Improve printing of nested-name-specifiers to eliminate redudant
qualifiers. Also, make it possible to output a nested-name-specifier
through a DiagnosticBuilder, although there are relatively few places
that will use this leeway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80056 91177308-0d34-0410-b5e6-96231b3b80d8
their members, including member class template, member function
templates, and member classes and functions of member templates.
To actually parse the nested-name-specifiers that qualify the name of
an out-of-line definition of a member template, e.g.,
template<typename X> template<typename Y>
X Outer<X>::Inner1<Y>::foo(Y) {
return X();
}
we need to look for the template names (e.g., "Inner1") as a member of
the current instantiation (Outer<X>), even before we have entered the
scope of the current instantiation. Since we can't do this in general
(i.e., we should not be looking into all dependent
nested-name-specifiers as if they were the current instantiation), we
rely on the parser to tell us when it is parsing a declaration
specifier sequence, and, therefore, when we should consider the
current scope specifier to be a current instantiation.
Printing of complicated, dependent nested-name-specifiers may be
somewhat broken by this commit; I'll add tests for this issue and fix
the problem (if it still exists) in a subsequent commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80044 91177308-0d34-0410-b5e6-96231b3b80d8
the logic is there for out-of-line definitions with multiple levels of
nested templates, but this is still a work-in-progress: we're having
trouble determining when we should look into a dependent
nested-name-specifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80003 91177308-0d34-0410-b5e6-96231b3b80d8
member templates declared inside other templates. This allows us to
match out-of-line definitions of member function templates within
class templates to the declarations within the class template. We
still can't handle out-of-line definitions for member class templates,
however.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79955 91177308-0d34-0410-b5e6-96231b3b80d8
that type. Note that we do not produce a diagnostic if the type is
incomplete; rather, we just don't look for conversion functions. Fixes PR4660.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79919 91177308-0d34-0410-b5e6-96231b3b80d8
and will participate in overload resolution. Unify the instantiation
of CXXMethodDecls and CXXConstructorDecls, which had already gotten
out-of-sync.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79658 91177308-0d34-0410-b5e6-96231b3b80d8
- Allowing one to name a member function template within a class
template and on the right-hand side of a member access expression.
- Template argument deduction for calls to member function templates.
- Registering specializations of member function templates (and
finding them later).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79581 91177308-0d34-0410-b5e6-96231b3b80d8
transform, then use the result for template instantiation. The generic
transformation fixes a few issues:
- It copes better with template template parameters and member
templates (when they're implemented).
- The logic used to replace template template parameters with their
arguments is now centralized in TransformDecl, so that it will apply
for other declaration-instantiation steps.
- The error-recovery strategy is normalized now, so that any error
results in a NULL TemplateName.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@78292 91177308-0d34-0410-b5e6-96231b3b80d8
template partial specialization. Then, use those template arguments
when instantiating members of that class template partial
specialization. Fixes PR4607.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77925 91177308-0d34-0410-b5e6-96231b3b80d8
Itanium C++ ABI's name mangling, since both are related to the notion
of "equivalent" function templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77678 91177308-0d34-0410-b5e6-96231b3b80d8
for those extra-esoteric cases. Not that any two given C++ compilers
agree on this test case, but this change gives us a strong definition
of equivalent types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77664 91177308-0d34-0410-b5e6-96231b3b80d8
current instantiation when that current instantiation is a class
template partial specialization.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77609 91177308-0d34-0410-b5e6-96231b3b80d8
template arguments, as in template specialization types. This permits
matching out-of-line definitions of members for class templates that
involve non-type template parameters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77462 91177308-0d34-0410-b5e6-96231b3b80d8
Doug, please look at decltype-crash and instantiate-function-1.mm, I'm not sure
if they are actually testing the right thing / anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77070 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
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
instantiation stack so that we provide a full instantiation
backtrace. Previously, we performed all of the instantiations implied
by the recursion, but each looked like a "top-level" instantiation.
The included test case tests the previous fix for the instantiation of
DeclRefExprs. Note that the "instantiated from" diagnostics still
don't tell us which template arguments we're instantiating with.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74540 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
handle function templates. There's no actual code for function
templates yet, but at least we complain about typedef templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74021 91177308-0d34-0410-b5e6-96231b3b80d8
specialization. At present, all implicit instantiations occur at the
end of the translation unit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73915 91177308-0d34-0410-b5e6-96231b3b80d8
<rdar://problem/6952203>.
To do this, we actually remove a not-quite-correct optimization in the
C++ name lookup routines. We'll revisit this optimization for the
general case once more C++ is working.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73659 91177308-0d34-0410-b5e6-96231b3b80d8
Implement support for C++ Substitution Failure Is Not An Error
(SFINAE), which says that errors that occur during template argument
deduction do *not* produce diagnostics and do not necessarily make a
program ill-formed. Instead, template argument deduction silently
fails. This is currently implemented for template argument deduction
during matching of class template partial specializations, although
the mechanism will also apply to template argument deduction for
function templates. The scheme is simple:
- If we are in a template argument deduction context, any diagnostic
that is considered a SFINAE error (or warning) will be
suppressed. The error will be propagated up the call stack via the
normal means.
- By default, all warnings and errors are SFINAE errors. Add the
NoSFINAE class to a diagnostic in the .td file to make it a hard
error (e.g., for access-control violations).
Note that, to make this fully work, every place in Sema that emits an
error *and then immediately recovers* will need to check
Sema::isSFINAEContext() to determine whether it must immediately
return an error rather than recovering.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73332 91177308-0d34-0410-b5e6-96231b3b80d8
I'm not completely sure this is the right way to fix this issue, but it seems
reasonable, and it's consistent with the non-template code for this
construct.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73285 91177308-0d34-0410-b5e6-96231b3b80d8
specialization cannot be deduced, produce a warning noting that the
affected class template partial specialization will never be used.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73274 91177308-0d34-0410-b5e6-96231b3b80d8
specialization's arguments are identical to the implicit template
arguments of the primary template. Typically, this is meant to be a
declaration/definition of the primary template, so we give that
advice.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73259 91177308-0d34-0410-b5e6-96231b3b80d8
partial specialization, substitute those template arguments back into
the template arguments of the class template partial specialization to
see if the results still match the original template arguments.
This code is more general than it needs to be, since we don't yet
diagnose C++ [temp.class.spec]p9. However, it's likely to be needed
for function templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73196 91177308-0d34-0410-b5e6-96231b3b80d8
Daniel Dunbar
Douglas Gregor
John McCall
Eli Friedman
Fariborz Jahanian
Sebastian Redl
Anders Carlsson
John Thompson
Owen Anderson
Mike Stump
Argyrios Kyrtzidis