| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
locations" into
a new class. Use it pervasively throughout Sema.
My fingers hurt.
llvm-svn: 89638
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
expressions
llvm-svn: 86989
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
such initializations properly convert constructor arguments and fill
in default arguments where necessary. This also makes the ownership
model more clear.
llvm-svn: 81394
|
|
|
|
| |
llvm-svn: 81346
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 81178
|
|
|
|
|
|
|
|
|
| |
for (unsigned i = numargs; i < NumArgs; ++i)
Args[0] = 0;
;)
llvm-svn: 81123
|
|
|
|
|
|
|
| |
destroying the CXXConstructExpr.", this is causing test failures across the
board.
llvm-svn: 81100
|
|
|
|
|
|
| |
destroying the CXXConstructExpr.
llvm-svn: 81096
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 79143
|
|
|
|
| |
llvm-svn: 78452
|
|
|
|
|
|
|
| |
or expression (Destroy) from the virtual function used to actually
destroy a given expression (DoDestroy).
llvm-svn: 78375
|
|
|
|
|
|
| |
work in progress.
llvm-svn: 78132
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 77510
|
|
|
|
|
|
|
|
| |
and __has_trivial_constructor builtin pseudo-functions and
additionally implements __has_trivial_copy and __has_trivial_assign,
from John McCall!
llvm-svn: 76916
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 76193
|
|
|
|
|
|
| |
Type::getAsMemberPointerType(), Type::getAsTagType(), and Type::getAsRecordType() with their Type::getAs<XXX> equivalents.
llvm-svn: 76139
|
|
|
|
|
|
|
| |
templates, such as make<int&>. These template-ids are only barely
functional for function calls; much more to come.
llvm-svn: 74563
|
|
|
|
| |
llvm-svn: 73462
|
|
|
|
|
|
| |
default arguments that have temporaries.
llvm-svn: 72944
|
|
|
|
| |
llvm-svn: 72643
|
|
|
|
| |
llvm-svn: 72634
|
|
|
|
| |
llvm-svn: 72633
|
|
|
|
| |
llvm-svn: 72628
|
|
|
|
| |
llvm-svn: 72627
|
|
|
|
| |
llvm-svn: 72626
|
|
|
|
|
|
|
|
|
|
|
|
| |
expressions. This change introduces another AST node,
CXXUnresolvedMemberExpr, that captures member references (x->m, x.m)
when the base of the expression (the "x") is type-dependent, and we
therefore cannot resolve the member reference yet.
Note that our parsing of member references for C++ is still quite
poor, e.g., we don't handle x->Base::m or x->operator int.
llvm-svn: 72281
|
|
|
|
|
|
| |
due to C++ type construction of the form T(a1, a2, ..., aN).
llvm-svn: 72183
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
describe the construction of a value of a given type using function
syntax, e.g.,
T(a1, a2, ..., aN)
when the type or any of its arguments are type-dependent. In this
case, we don't know what kind of type-construction this will be: it
might construct a temporary of type 'T' (which might be a class or
non-class type) or might perform a conversion to type 'T'. Also,
implement printing of and template instantiation for this new
expression type. Due to the change in Sema::ActOnCXXTypeConstructExpr,
our existing tests cover template instantiation of this new expression
node.
llvm-svn: 72176
|
|
|
|
| |
llvm-svn: 72081
|
|
|
|
|
|
| |
these are testable yet, though.
llvm-svn: 71953
|
|
|
|
| |
llvm-svn: 71405
|
|
|
|
| |
llvm-svn: 70586
|
|
|
|
| |
llvm-svn: 70584
|
|
|
|
| |
llvm-svn: 70086
|
|
|
|
| |
llvm-svn: 70000
|
|
|
|
| |
llvm-svn: 69981
|
|
|
|
| |
llvm-svn: 69959
|
|
|
|
|
|
| |
unused for now, so no functionality change yet. Also, create CXXTempVarDecls to pass to the CXXTemporaryObjectExpr ctor.
llvm-svn: 69957
|
|
|
|
|
|
| |
change.
llvm-svn: 69954
|
|
|
|
|
|
| |
constructor. I think CXXTemporaryObjectExpr is going to become a subclass of CXXConstructExpr, since CXXTemporaryObjectExpr represents a syntactic temporary, for example T()
llvm-svn: 69854
|
|
|
|
| |
llvm-svn: 69654
|
|
|
|
| |
llvm-svn: 69345
|
|
|
|
| |
llvm-svn: 69245
|