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
t->Base::f
where t has a dependent type. We save the nested-name-specifier in the
CXXUnresolvedMemberExpr then, during instantiation, substitute into
the nested-name-specifier with the (transformed) object type of t, so
that we get name lookup into the type of the object expression.
Note that we do not yet retain information about name lookup into the
lexical scope of the member access expression, so several regression
tests are still disabled.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80925 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
space within the MemberExpr for the nested-name-specifier and its
source range. We'll do the same thing with explicitly-specified
template arguments, assuming I don't flip-flop again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80642 91177308-0d34-0410-b5e6-96231b3b80d8
also be adding explicit template arguments as an additional
"adornment". No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80628 91177308-0d34-0410-b5e6-96231b3b80d8
name, e.g.,
x->Base::f()
retain the qualifier (and its source range information) in a new
subclass of MemberExpr called CXXQualifiedMemberExpr. Provide
construction, transformation, profiling, printing, etc., for this new
expression type.
When a virtual function is called via a qualified name, don't emit a
virtual call. Instead, call that function directly. Mike, could you
add a CodeGen test for this, too?
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80167 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
This is a Type subclass that can hold a DeclaratorInfo* when we have type source info coming
out of a declarator that we want to preserve. This is used only at the "border" of Parser/Sema for
passing/getting QualTypes, it does not participate in the type system semantics in any way.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79394 91177308-0d34-0410-b5e6-96231b3b80d8
Removed an unnecessary loop to get to setters incoming
argument. Added DoxyGen comments. Still more work
to do in this area (WIP).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79365 91177308-0d34-0410-b5e6-96231b3b80d8
generic tree transformation (also used for recanonicalization) and a
small amount of template-instantiation-specific logic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@78645 91177308-0d34-0410-b5e6-96231b3b80d8
we were going to enter into the scope of a class template or class
template partial specialization, rebuild that type so that it can
refer to members of the current instantiation, as in code like
template<typename T>
struct X {
typedef T* pointer;
pointer data();
};
template<typename T>
typename X<T>::pointer X<T>::data() { ... }
Without rebuilding the return type of this out-of-line definition, the
canonical return type of the out-of-line definition (a TypenameType)
will not match the canonical return type of the declaration (the
canonical type of T*).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@78316 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
tree transformation. Template instantiation uses this general
transformation rather than implementing its own transformation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@78286 91177308-0d34-0410-b5e6-96231b3b80d8
general tree transformation. Also, implement template instantiation
for parameter packs.
In addition, introduce logic to enter the appropriate context for
subexpressions that are not potentially evaluated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@78114 91177308-0d34-0410-b5e6-96231b3b80d8
transformation template (TreeTransform) that handles the
transformation and reconstruction of AST nodes. Template instantiation
for types is a (relatively small) customization of the generic tree
transformation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@78071 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor
Anders Carlsson
Chris Lattner
Fariborz Jahanian
Argyrios Kyrtzidis