| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
uniqued representation that should both save some memory and make it
far easier to properly build canonical types for types involving
dependent nested-name-specifiers, e.g., "typename T::Nested::type".
This approach will greatly simplify the representation of
CXXScopeSpec. That'll be next.
llvm-svn: 67799
|
|
|
|
|
|
| |
used for the __is_abstract type trait.
llvm-svn: 67461
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dependent qualified-ids such as
Fibonacci<N - 1>::value
where N is a template parameter. These references are "unresolved"
because the name is dependent and, therefore, cannot be resolved to a
declaration node (as we would do for a DeclRefExpr or
QualifiedDeclRefExpr). UnresolvedDeclRefExprs instantiate to
DeclRefExprs, QualifiedDeclRefExprs, etc.
Also, be a bit more careful about keeping only a single set of
specializations for a class template, and instantiating from the
definition of that template rather than a previous declaration. In
general, we need a better solution for this for all TagDecls, because
it's too easy to accidentally look at a declaration that isn't the
definition.
We can now process a simple Fibonacci computation described as a
template metaprogram.
llvm-svn: 67308
|
|
|
|
|
|
|
|
| |
QualifiedNameType and QualifiedDeclRefExpr. We now keep track of the
exact nested-name-specifier spelling for a QualifiedDeclRefExpr, and
use that spelling when printing ASTs. This fixes PR3493.
llvm-svn: 67283
|
|
|
|
|
|
|
|
|
|
|
|
| |
- C++ function casts, e.g., T(foo)
- sizeof(), alignof()
More importantly, this allows us to verify that we're performing
overload resolution during template instantiation, with
argument-dependent lookup and the "cached" results of name lookup from
the template definition.
llvm-svn: 66947
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instantiation for binary operators. This change moves most of the
operator-overloading code from the parser action ActOnBinOp to a new,
parser-independent semantic checking routine CreateOverloadedBinOp.
Of particular importance is the fact that CreateOverloadedBinOp does
*not* perform any name lookup based on the current parsing context (it
doesn't take a Scope*), since it has to be usable during template
instantiation, when there is no scope information. Rather, it takes a
pre-computed set of functions that are visible from the context or via
argument-dependent lookup, and adds to that set any member operators
and built-in operator candidates. The set of functions is computed in
the parser action ActOnBinOp based on the current context (both
operator name lookup and argument-dependent lookup). Within a
template, the set computed by ActOnBinOp is saved within the
type-dependent AST node and is augmented with the results of
argument-dependent name lookup at instantiation time (see
TemplateExprInstantiator::VisitCXXOperatorCallExpr).
Sadly, we can't fully test this yet. I'll follow up with template
instantiation for sizeof so that the real fun can begin.
llvm-svn: 66923
|
|
|
|
| |
llvm-svn: 65529
|