Commit Graph

836 Commits

Author SHA1 Message Date
John McCall b96ec56871 Fix "using typename" and the instantiation of non-dependent using declarations.
llvm-svn: 90614
2009-12-04 22:46:56 +00:00
Eli Friedman 2cfcef65b7 Make the type of the Decl referred to by a MemberExpr a bit more precise.
llvm-svn: 90549
2009-12-04 06:40:45 +00:00
John McCall 2d74de9632 Rework how we support C++ implicit member accesses. If we can resolve an
implicit member access to a specific declaration, go ahead and create
it as a DeclRefExpr or a MemberExpr (with implicit CXXThisExpr base) as
appropriate.  Otherwise, create an UnresolvedMemberExpr or
DependentScopeMemberExpr with a null base expression.

By representing implicit accesses directly in the AST, we get the ability
to correctly delay the decision about whether it's actually an instance
member access or not until resolution is complete.  This permits us
to correctly avoid diagnosing the 'problem' of 'MyType::foo()'
where the relationship to the type isn't really known until instantiation.

llvm-svn: 90266
2009-12-01 22:10:20 +00:00
John McCall 10eae1851d Eliminate the use of OverloadedFunctionDecl in member expressions.
Create a new UnresolvedMemberExpr for these lookups.  Assorted hackery
around qualified member expressions;  this will all go away when we
implement the correct (i.e. extremely delayed) implicit-member semantics.

llvm-svn: 90161
2009-11-30 22:42:35 +00:00
Alexis Hunt 3d221f2fce Add DeclarationName support for C++0x operator literals. They should now work as
function names outside of templates - they'll probably cause some damage there as
they're largely untested.

llvm-svn: 90064
2009-11-29 07:34:05 +00:00
Fariborz Jahanian 906d871e6c Some fancy footwork to move the decision on how
to build casted expression-list AST to Sema.

llvm-svn: 89827
2009-11-25 01:26:41 +00:00
Douglas Gregor 7bab5ff8e7 Eliminate CXXConditionDeclExpr with extreme prejudice.
All statements that involve conditions can now hold on to a separate
condition declaration (a VarDecl), and will use a DeclRefExpr
referring to that VarDecl for the condition expression. ForStmts now
have such a VarDecl (I'd missed those in previous commits).

Also, since this change reworks the Action interface for
if/while/switch/for, use FullExprArg for the full expressions in those
expressions, to ensure that we're emitting

Note that we are (still) not generating the right cleanups for
condition variables in for statements. That will be a follow-on
commit.

llvm-svn: 89817
2009-11-25 00:27:52 +00:00
Douglas Gregor 680f861d74 Clean up the AST for while loops and fix several problems with
cleanups for while loops: 

1) Make sure that we destroy the condition variable of a while statement each time through the loop for, e.g.,

   while (shared_ptr<WorkInt> p = getWorkItem()) {
         // ...
         }

2) Make sure that we always enter a new cleanup scope for the body of the while loop, even when there is no compound expression, e.g.,

   while (blah)
     RAIIObject raii(blah+1);

llvm-svn: 89800
2009-11-24 21:15:44 +00:00
John McCall e66edc18ae Rip out TemplateIdRefExpr and make UnresolvedLookupExpr and
DependentScopeDeclRefExpr support storing templateids.  Unite the common   
code paths between ActOnDeclarationNameExpr and ActOnTemplateIdExpr.

This gets us to a point where we don't need to store function templates in
the AST using TemplateNames, which is critical to ripping out OverloadedFunction.

Also resolves a few FIXMEs.

llvm-svn: 89785
2009-11-24 19:00:30 +00:00
Douglas Gregor dcf1962405 Explicitly store the condition variable within switch statements, and
make sure that this variable is destroyed when we exit the switch
statement.

llvm-svn: 89776
2009-11-24 17:07:59 +00:00
Douglas Gregor 633caca353 Explicitly track the condition variable within an "if" statement,
rather than burying it in a CXXConditionDeclExpr (that occassionally
hides behind implicit conversions). Similar changes for
switch, while, and do-while will follow, then the removal of
CXXConditionDeclExpr. This commit is the canary.

llvm-svn: 89717
2009-11-23 23:44:04 +00:00
Douglas Gregor ed6c744091 Centralize and complete the computation of value- and type-dependence for DeclRefExprs
llvm-svn: 89649
2009-11-23 11:41:28 +00:00
John McCall 6b51f28e82 Encapsulate "an array of TemplateArgumentLocs and two angle bracket locations" into
a new class.  Use it pervasively throughout Sema.

My fingers hurt.

llvm-svn: 89638
2009-11-23 01:53:49 +00:00
John McCall d14a86427f "Incremental" progress on using expressions, by which I mean totally ripping
into pretty much everything about overload resolution in order to wean
BuildDeclarationNameExpr off LookupResult::getAsSingleDecl().  Replace  
UnresolvedFunctionNameExpr with UnresolvedLookupExpr, which generalizes the
idea of a non-member lookup that we haven't totally resolved yet, whether by
overloading, argument-dependent lookup, or (eventually) the presence of   
a function template in the lookup results.  

Incidentally fixes a problem with argument-dependent lookup where we were 
still performing ADL even when the lookup results contained something from
a block scope.  

Incidentally improves a diagnostic when using an ObjC ivar from a class method.
This just fell out from rewriting BuildDeclarationNameExpr's interaction with
lookup, and I'm too apathetic to break it out.

The only remaining uses of OverloadedFunctionDecl that I know of are in
TemplateName and MemberExpr.

llvm-svn: 89544
2009-11-21 08:51:07 +00:00
Douglas Gregor ade9bcd72e Cope with extraneous "template" keyword when providing an out-of-line
definition of a member template (or a member thereof). Fixes PR5566.

llvm-svn: 89512
2009-11-20 23:39:24 +00:00
John McCall 8cd7813ca3 Draw a brighter line between "unresolved" expressions, where we have done the
appropriate lookup and simply can't resolve the referrent yet, and
"dependent scope" expressions, where we can't do the lookup yet because the
entity we need to look into is a dependent type.

llvm-svn: 89402
2009-11-19 22:55:06 +00:00
Eli Friedman 06577388d7 The sub-statement of a case statement is not an unevaluated context!
llvm-svn: 89303
2009-11-19 03:14:00 +00:00
Douglas Gregor 1b8fe5b716 First part of changes to eliminate problems with cv-qualifiers and
sugared types. The basic problem is that our qualifier accessors
(getQualifiers, getCVRQualifiers, isConstQualified, etc.) only look at
the current QualType and not at any qualifiers that come from sugared
types, meaning that we won't see these qualifiers through, e.g.,
typedefs:

  typedef const int CInt;
  typedef CInt Self;

Self.isConstQualified() currently returns false!

Various bugs (e.g., PR5383) have cropped up all over the front end due
to such problems. I'm addressing this problem by splitting each
qualifier accessor into two versions: 

  - the "local" version only returns qualifiers on this particular
    QualType instance
  - the "normal" version that will eventually combine qualifiers from this
    QualType instance with the qualifiers on the canonical type to
    produce the full set of qualifiers.

This commit adds the local versions and switches a few callers from
the "normal" version (e.g., isConstQualified) over to the "local"
version (e.g., isLocalConstQualified) when that is the right thing to
do, e.g., because we're printing or serializing the qualifiers. Also,
switch a bunch of
  
  Context.getCanonicalType(T1).getUnqualifiedType() == Context.getCanonicalType(T2).getQualifiedType()

expressions over to 

  Context.hasSameUnqualifiedType(T1, T2)

llvm-svn: 88969
2009-11-16 21:35:15 +00:00
Eli Friedman f2f534d12a Fix PR5488: special-case the overloaded arrow operator so that we don't try to
treat it as a unary operator.

llvm-svn: 88938
2009-11-16 19:13:03 +00:00
Douglas Gregor 07eae02fc7 When transforming an expression statement (e.g., for template
instantiation), be sure to finish the expression statement by
providing a FullExprArg, making sure that temporaries get
destroyed. Fixes an obscure failure when parsing
llvm/LinkAllPasses.h.

llvm-svn: 88668
2009-11-13 18:34:26 +00:00
Douglas Gregor 9167f8bbd5 Introduce a new representation for template template
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. 

llvm-svn: 86777
2009-11-11 01:00:40 +00:00
Douglas Gregor d3d9306275 When transforming an InitListExpr, if we already computed a non-dependent type for the InitListExpr, keep it
llvm-svn: 86559
2009-11-09 17:16:50 +00:00
Douglas Gregor 5287f091b2 When instantiating a UnaryOperator, allow the resulting expression to
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.

llvm-svn: 86087
2009-11-05 00:51:44 +00:00
Douglas Gregor b184f0d32e When instantiating a MemberExpr, be sure to instantiate the
explicitly-specified template arguments, too!

llvm-svn: 86066
2009-11-04 23:20:05 +00:00
John McCall 4c98fd8953 Preserve type source information in sizeof/alignof expressions, and pass it
through to indexing.

llvm-svn: 86018
2009-11-04 07:28:41 +00:00
Douglas Gregor c95a1fa7f6 When performing template instantiation (transformation) of
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.

llvm-svn: 86017
2009-11-04 07:01:15 +00:00
Douglas Gregor 71395fa1d5 Implement support for parsing dependent template-ids that refer to
overloaded operators, e.g.,

  p->template operator+<T>()

llvm-svn: 85989
2009-11-04 00:56:37 +00:00
Douglas Gregor 3cf81317e4 Parsing and semantic analysis for template-ids that name overloaded
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.

llvm-svn: 85966
2009-11-03 23:16:33 +00:00
Douglas Gregor 30d60cb36e Replace the code that parses member access expressions after "." or
"->" with a use of ParseUnqualifiedId. Collapse
ActOnMemberReferenceExpr, ActOnDestructorReferenceExpr (both of them),
ActOnOverloadedOperatorReferenceExpr,
ActOnConversionOperatorReferenceExpr, and
ActOnMemberTemplateIdReferenceExpr into a single, new action
ActOnMemberAccessExpr that does the same thing more cleanly (and can
keep more source-location information).

llvm-svn: 85930
2009-11-03 19:44:04 +00:00
John McCall 70dd5f6574 Report accurate source-location information when rebuilding types during
template instantiation.

llvm-svn: 85545
2009-10-30 00:06:24 +00:00
Douglas Gregor 07cc4ac606 Slightly improve source-location information during template instantiation
llvm-svn: 85529
2009-10-29 22:21:39 +00:00
Sebastian Redl adba46edc2 Properly instantiate usage of overloaded operator []. Fixes PR5345.
llvm-svn: 85524
2009-10-29 20:17:01 +00:00
John McCall 0d07eb32de A few TemplateArgumentLoc clean-ups. Try to remember the Expr for a declaration.
Provide an API for getting the SourceRange of a TAL and use it judiciously.

llvm-svn: 85520
2009-10-29 18:45:58 +00:00
Douglas Gregor ba91b89711 Yet more instantiation-location information. Fixes PR5336.
llvm-svn: 85516
2009-10-29 17:56:10 +00:00
John McCall 0ad166672f Track source information for template arguments and template specialization
types.  Preserve it through template instantiation.  Preserve it through PCH,
although TSTs themselves aren't serializable, so that's pretty much meaningless.

llvm-svn: 85500
2009-10-29 08:12:44 +00:00
Douglas Gregor 3da3c06578 Slightly improve source location information during template instantiation
llvm-svn: 85353
2009-10-28 00:29:27 +00:00
Douglas Gregor ef6ab417c1 Only set the point of instantiation for an implicit or explicit
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.

llvm-svn: 85209
2009-10-27 06:26:26 +00:00
Sebastian Redl c057f423a0 Apply the special enum restrictions from [over.match.oper]p3b2 in argument-dependent lookup too. This fixes PR5244.
llvm-svn: 84963
2009-10-23 19:23:15 +00:00
Douglas Gregor 4bd90e53c2 Eliminate QualifiedDeclRefExpr, which captured the notion of a
qualified reference to a declaration that is not a non-static data
member or non-static member function, e.g., 

  namespace N { int i; }
  int j = N::i;

Instead, extend DeclRefExpr to optionally store the qualifier. Most
clients won't see or care about the difference (since
QualifierDeclRefExpr inherited DeclRefExpr). However, this reduces the
number of top-level expression types that clients need to cope with,
brings the implementation of DeclRefExpr into line with MemberExpr,
and simplifies and unifies our handling of declaration references.

Extended DeclRefExpr to (optionally) store explicitly-specified
template arguments. This occurs when naming a declaration via a
template-id (which will be stored in a TemplateIdRefExpr) that,
following template argument deduction and (possibly) overload
resolution, is replaced with a DeclRefExpr that refers to a template
specialization but maintains the template arguments as written.

llvm-svn: 84962
2009-10-23 18:54:35 +00:00
John McCall 24e7cb6f26 Rebuild dependently-sized ext vectors if either the element type or the size
changed under the transform.

llvm-svn: 84953
2009-10-23 17:55:45 +00:00
Benjamin Kramer 0c78c7aa20 Silence GCC 4.3 warning.
TreeTransform.h:2333: warning: suggest parentheses around && within ||

llvm-svn: 84949
2009-10-23 10:48:09 +00:00
John McCall fc93cf9777 When building types from declarators, instead of building two types (one for
the DeclaratorInfo, one for semantic analysis), just build a single type whose
canonical type will reflect the semantic analysis (assuming the type is
well-formed, of course).

To make that work, make a few changes to the type system:
* allow the nominal pointee type of a reference type to be a (possibly sugared)
  reference type.  Also, preserve the original spelling of the reference type.
  Both of these can be ignored on canonical reference types.
* Remove ObjCProtocolListType and preserve the associated source information on
  the various ObjC TypeLocs.  Preserve the spelling of protocol lists except in
  the canonical form.
* Preserve some level of source type structure on parameter types, but
  canonicalize on the canonical function type.  This is still a WIP.

Drops code size, makes strides towards accurate source location representation,
slight (~1.7%) progression on Cocoa.h because of complexity drop.

llvm-svn: 84907
2009-10-22 22:37:11 +00:00
Douglas Gregor d019ff686c When building and instantiating a template-id reference expression, such as
N::f<int>

keep track of the full nested-name-specifier. This is mainly QoI and
relatively hard to test; will try to come up with a printing-based
test once we also retain the explicit template arguments past overload
resolution.

llvm-svn: 84869
2009-10-22 17:20:55 +00:00
John McCall de88989e5d Initialize using the base location provided by the derived implementation,
not the default one (which is always empty).

llvm-svn: 84721
2009-10-21 00:44:26 +00:00
John McCall 550e0c2f0f Rewrite TreeTransform to transform types as DeclaratorInfos rather than as bare
QualTypes.  Don't actually exploit this yet.

llvm-svn: 84716
2009-10-21 00:40:46 +00:00
Douglas Gregor a5cb6da0cd Handle substitutions into the "first qualifier in scope" of a
qualified member access expression (e.g., t->U::member) when that
first qualifier refers to a template parameters.

llvm-svn: 84612
2009-10-20 05:58:46 +00:00
Douglas Gregor c59e56190e Parse a simple-template-id following a '~' when calling a destructor, e.g.,
t->~T<A0, A1>()

Fixes PR5213.

llvm-svn: 84545
2009-10-19 22:04:39 +00:00
John McCall cebee16bc0 When performing template-substitution into a type, don't just replace the
TemplateTypeParmType with the substituted type directly;  instead, replace it
with a SubstTemplateTypeParmType which will note that the type was originally
written as a template type parameter.  This makes it reasonable to preserve
source information even through template substitution.

Also define the new SubstTemplateTypeParmType class, obviously.

For consistency with current behavior, we stringize these types as if they
were the underlying type.  I'm not sure this is the right thing to do.
At any rate, I paled at adding yet another clause to the don't-desugar 'if'
statement, so I extracted a function to do it.  The new function also does
The Right Thing more often, I think:  e.g. if we have a chain of typedefs
leading to a vector type, we will now desugar all but the last one.

llvm-svn: 84412
2009-10-18 09:09:24 +00:00
John McCall c5b8225285 Remove the ConstantArrayType subtypes. This information is preserved in the
TypeLoc records for declarations;  it should not be necessary to represent it
directly in the type system.

Please complain if you were using these classes and feel you can't replicate
previous functionality using the TypeLoc API.

llvm-svn: 84222
2009-10-16 00:14:28 +00:00
Argyrios Kyrtzidis a7a36dfdb6 Introduce ObjCProtocolListType type subclass.
This is used only for keeping detailed type source information for protocol references,
it should not participate in the semantics of the type system.

Its protocol list is not canonicalized.

llvm-svn: 83093
2009-09-29 19:42:55 +00:00
John McCall 8ccfcb51ee Refactor the representation of qualifiers to bring ExtQualType out of the
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.

llvm-svn: 82705
2009-09-24 19:53:00 +00:00
Mike Stump 11289f4280 Remove tabs, and whitespace cleanups.
llvm-svn: 81346
2009-09-09 15:08:12 +00:00
Douglas Gregor 308047d3a5 Initial stab at implement dependent member references to member
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.

llvm-svn: 81300
2009-09-09 00:23:06 +00:00
Anders Carlsson 5995a3e8fa BuildCXXConstructExpr now takes a MultiExprArg.
llvm-svn: 81160
2009-09-07 22:23:31 +00:00
Anders Carlsson 1b4ebfab2b Pass the ConstructLoc to BuildCXXConstructExpr.
llvm-svn: 81068
2009-09-05 07:40:38 +00:00
John McCall fcc33b074b Basic support for representing elaborated type specifiers
directly in the AST.  The current thinking is to create these
only in C++ mode for efficiency.  But for now, they're not being
created at all; patch to follow.

This will let us do things like verify that tags match during
template instantation, as well as signal that an elaborated type
specifier was used for clients that actually care.

Optimally, the TypeLoc hierarchy should be adjusted to carry tag
location information as well.

llvm-svn: 81057
2009-09-05 00:15:47 +00:00
Douglas Gregor ad8a336b40 Implement AST, semantics, and CodeGen for C++ pseudo-destructor
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.

llvm-svn: 81009
2009-09-04 17:36:40 +00:00
Douglas Gregor f816bd70ce Implement tree transformations for DeclarationNames. Among other
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).

llvm-svn: 80957
2009-09-03 22:13:48 +00:00
Douglas Gregor 2b6ca46c6b Improve template instantiation for member access expressions that
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.

llvm-svn: 80953
2009-09-03 21:38:09 +00:00
Douglas Gregor c26e0f626b Improved handling for dependent, qualified member access expressions, e.g.,
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.

llvm-svn: 80925
2009-09-03 16:14:30 +00:00
Douglas Gregor b7bfe79412 Rewrite of our handling of name lookup in C++ member access expressions, e.g.,
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.

llvm-svn: 80843
2009-09-02 22:59:36 +00:00
Douglas Gregor 32e2c8472e Fix a crasher involving template instantiation of non-dependent
expressions making use of an overloaded operator. Thanks for the test
case, Anders!

llvm-svn: 80679
2009-09-01 16:58:52 +00:00
Anders Carlsson 5da848427a Don't assert when instantiating member references to fields in anonymous structs.
llvm-svn: 80657
2009-09-01 04:26:58 +00:00
Douglas Gregor 84f14dd674 Preliminary AST representation and semantic analysis for
explicitly-specified template argument lists in member reference
expressions, e.g.,

  x->f<int>()

llvm-svn: 80646
2009-09-01 00:37:14 +00:00
Douglas Gregor f405d7e6f1 Eliminate CXXAdornedMemberExpr entirely. Instead, optionally allocate
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.

llvm-svn: 80642
2009-08-31 23:41:50 +00:00
Douglas Gregor 96ee789d33 Rename CXXQualifiedMemberExpr -> CXXAdornedMemberExpr, since we will
also be adding explicit template arguments as an additional
"adornment". No functionality change.

llvm-svn: 80628
2009-08-31 21:41:48 +00:00
Douglas Gregor f14b46f9a8 Implement template instantiation for member operator access.
llvm-svn: 80609
2009-08-31 20:00:26 +00:00
Douglas Gregor c190523d7a When a member reference expression includes a qualifier on the member
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?

llvm-svn: 80167
2009-08-26 22:36:53 +00:00
Douglas Gregor 7e112b0d79 Source location information for ? and : in a ConditionalOperator, from Enea Zaffanella
llvm-svn: 80097
2009-08-26 14:37:04 +00:00
Douglas Gregor e861bac059 Improve support for out-of-line definitions of nested templates and
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.

llvm-svn: 80044
2009-08-25 22:51:20 +00:00
Anders Carlsson 6eb55575da BuildCXXConstructExpr now returns an OwningExprResult.
llvm-svn: 79975
2009-08-25 05:12:04 +00:00
Chris Lattner dca19591f2 fix a GCC type punning warning.
llvm-svn: 79895
2009-08-24 05:19:01 +00:00
Fariborz Jahanian 9a84665921 Using "ObjCImplicitSetterGetterRefExpr" instead of "ObjCImplctSetterGetterRefExpr".
A field rename and more comments.

llvm-svn: 79537
2009-08-20 17:02:02 +00:00
Douglas Gregor ebe1010b0f Refactor the instantiation of statements into a generic tree
transformation.

llvm-svn: 79519
2009-08-20 07:17:43 +00:00
Argyrios Kyrtzidis e918926d31 Introduce LocInfoType which is a Sema-specific implementation detail.
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.

llvm-svn: 79394
2009-08-19 01:28:17 +00:00
Fariborz Jahanian 88cc2340de Renamed ObjCKVCRefExpr to ObjCImplctSetterGetterRefExpr.
Removed an unnecessary loop to get to setters incoming
argument. Added DoxyGen comments. Still more work
to do in this area (WIP).

llvm-svn: 79365
2009-08-18 20:50:23 +00:00
Anders Carlsson f86a8d1030 BuildCXXConstructExpr doesn't need to take an ASTContext.
llvm-svn: 79149
2009-08-15 23:41:35 +00:00
Anders Carlsson e827123f08 Make the CXXDefaultArgExpr constructor protected and add a static Create function.
llvm-svn: 79013
2009-08-14 18:30:22 +00:00
Douglas Gregor 2168a9f25f Fix DISABLE_SMART_POINTERS build
llvm-svn: 78674
2009-08-11 15:56:57 +00:00
Douglas Gregor a16548e301 Refactor the template-instantiation logic for expressions into a
generic tree transformation (also used for recanonicalization) and a
small amount of template-instantiation-specific logic.

llvm-svn: 78645
2009-08-11 05:31:07 +00:00
Douglas Gregor 766b0bbe61 Minor refactoring to introduce a new transformation function,
TransformStmt, into the tree transformer.

llvm-svn: 78347
2009-08-06 22:17:10 +00:00
Douglas Gregor 15acfb9f50 When we encounter a dependent type that was parsed before we know that
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*).

llvm-svn: 78316
2009-08-06 16:20:37 +00:00
Douglas Gregor 71dc50915a Implement transformation of template names within the generic tree
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.

llvm-svn: 78292
2009-08-06 06:41:21 +00:00
Douglas Gregor 1135c35c7c Implement transformation of nested-name-specifiers within the general
tree transformation. Template instantiation uses this general
transformation rather than implementing its own transformation.

llvm-svn: 78286
2009-08-06 05:28:30 +00:00
Douglas Gregor e922c77ddd Move the template instantiation logic for template arguments into the
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.

llvm-svn: 78114
2009-08-04 22:27:00 +00:00
Douglas Gregor d6ff33294a Refactor template instantiation for types into a generic tree
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.

llvm-svn: 78071
2009-08-04 16:50:30 +00:00