| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 102379
|
| |
|
|
|
|
|
|
| |
references and isa expressions. Also, test template instantiation of
unresolved member references to Objective-C ivar references and isa
expressions.
llvm-svn: 102374
|
| |
|
|
|
|
| |
statements. This is the last of the Objective-C statements.
llvm-svn: 102356
|
| |
|
|
|
|
|
| |
(e.g., no typename, enum, class, etc.), e.g., because the context is
one that is known to refer to a type. Patch from Enea Zaffanella!
llvm-svn: 102243
|
| |
|
|
|
|
|
|
|
|
| |
statements. Instead of the @try having a single @catch, where all of
the @catch's were chained (using an O(n^2) algorithm nonetheless),
@try just holds an array of its @catch blocks. The resulting AST is
slightly more compact (not important) and better represents the actual
language semantics (good).
llvm-svn: 102221
|
| |
|
|
| |
llvm-svn: 102147
|
| |
|
|
|
|
|
|
|
|
| |
statement, i.e.,
for (element in collection) {
// do something
}
llvm-svn: 102138
|
| |
|
|
| |
llvm-svn: 102134
|
| |
|
|
| |
llvm-svn: 102133
|
| |
|
|
|
|
|
| |
template instantiation, since they cannot be dependent or have
dependent parts. Handle them the simple way.
llvm-svn: 102094
|
| |
|
|
|
|
|
|
| |
method being called at template definition time, retain that method
and pass it through to type-checking. We will not perform any lookup
for the method during template instantiation.
llvm-svn: 102081
|
| |
|
|
|
|
|
| |
Sema::BuildClassMessage; we weren't using it, and template
instantiation was faking it anyway.
llvm-svn: 102074
|
| |
|
|
|
|
| |
functionality change
llvm-svn: 102073
|
| |
|
|
|
|
|
|
|
|
|
|
| |
support dependent receivers for class and instance messages, along
with dependent message arguments (of course), and check as much as we
can at template definition time.
This commit also deals with a subtle aspect of template instantiation
in Objective-C++, where the type 'T *' can morph from a dependent
PointerType into a non-dependent ObjCObjectPointer type.
llvm-svn: 102071
|
| |
|
|
| |
llvm-svn: 101994
|
| |
|
|
|
|
| |
@encode expression.
llvm-svn: 101907
|
| |
|
|
|
|
|
|
| |
function declaration, since it may end up being changed (e.g.,
"extern" can become "static" if a prior declaration was static). Patch
by Enea Zaffanella and Paolo Bolzoni.
llvm-svn: 101826
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nested-name-specifier (e.g., "class T::foo") fails to find a tag
member in the scope nominated by the
nested-name-specifier. Previously, we gave a bland
error: 'Nested' does not name a tag member in the specified scope
which didn't actually say where we were looking, which was rather
horrible when the nested-name-specifier was instantiated. Now, we give
something a bit better:
error: no class named 'Nested' in 'NoDepBase<T>'
llvm-svn: 100060
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
(such as "class T::foo") from an ElaboratedType of a TypenameType to a
DependentNameType, which more accurately models the underlying
concept.
Improve template instantiation for DependentNameType nodes that
represent nested-name-specifiers, by performing tag name lookup and
checking the resulting tag appropriately. Fixes PR5681.
There is still much testing and cleanup to do in this area.
llvm-svn: 100054
|
| |
|
|
|
|
|
| |
this was parsed as a typename-specifier, elaborated-type-specifier
(including the kind), or just a dependent qualified type name.
llvm-svn: 100039
|
| |
|
|
|
|
|
| |
instantiating a template, which ensures the destructor is called. This fixes
PR6671.
llvm-svn: 100029
|
| |
|
|
|
|
| |
refactoring work in this area.
llvm-svn: 100019
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
the underlying/instantiated decl) through a lot of API, including "intermediate"
MemberExprs required for (e.g.) template instantiation. This is necessary
because of the access semantics of member accesses to using declarations:
only the base class *containing the using decl* need be accessible from the
naming class.
This allows us to complete an access-controlled selfhost, if there are no
recent regressions.
llvm-svn: 99936
|
| |
|
|
|
|
| |
there's a good equivalent that's actually true, unfortunately.
llvm-svn: 98253
|
| |
|
|
|
|
|
|
|
|
|
| |
instantiation. Based on a patch by Enea Zaffanella! I found a way to
reduce some of the redundancy between TreeTransform's "standard"
FunctionProtoType transformation and TemplateInstantiator's override,
and I killed off the old SubstFunctionType by adding type source info
for the last cases where we were creating FunctionDecls without TSI
(at least that get passed through template instantiation).
llvm-svn: 98252
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
injected class name of a class template or class template partial specialization.
This is a non-canonical type; the canonical type is still a template
specialization type. This becomes the TypeForDecl of the pattern declaration,
which cleans up some amount of code (and complicates some other parts, but
whatever).
Fixes PR6326 and probably a few others, primarily by re-establishing a few
invariants about TypeLoc sizes.
llvm-svn: 98134
|
| |
|
|
| |
llvm-svn: 97686
|
| |
|
|
| |
llvm-svn: 97677
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nested-name-specifier. For example, this allows member access in
diamond-shaped hierarchies like:
struct Base {
void Foo();
int Member;
};
struct D1 : public Base {};
struct D2 : public Base {};
struct Derived : public D1, public D2 { }
void Test(Derived d) {
d.Member = 17; // error: ambiguous cast from Derived to Base
d.D1::Member = 17; // error: okay, modify D1's Base's Member
}
Fixes PR5820 and <rdar://problem/7535045>. Also, eliminate some
redundancy between Sema::PerformObjectMemberConversion() and
Sema::PerformObjectArgumentInitialization() -- the latter now calls
the former.
llvm-svn: 97674
|
| |
|
|
|
|
|
| |
used to do this, but it got lost when we switched functional-style
cast syntax over to using the new initialization code. Fixes PR6457.
llvm-svn: 97568
|
| |
|
|
|
|
| |
TransformDefinition.
llvm-svn: 97445
|
| |
|
|
|
|
|
| |
given declaration in a template, make sure that the context we're
searching through is complete. Fixes PR6376.
llvm-svn: 97444
|
| |
|
|
|
|
|
|
|
| |
used when we instantiate C++ new expressions, delete expressions, and
object-construction expressions. Fixes PR6424, although we can't test
all of it until we finish implementing lookup of "operator delete" for
new expressions (!).
llvm-svn: 97195
|
| |
|
|
|
|
|
|
| |
to mark the constructor as referenced. Fixes the narrow issue reported
in PR6424, but there are a few other places that I'll fix before
closing out that PR.
llvm-svn: 97185
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compilation using g++ v3.4.
I'll watch the buildbots and back out if necessary.
Feel free to do the same if something breaks.
Without this patch I get (on g++ 3.4.6) following error:
In file included from clang/lib/Sema/SemaTemplate.cpp:14:
clang/lib/Sema/TreeTransform.h: In member function `clang::ASTOwningResult<&clang::ActionBase::DeleteExpr> clang::TreeTransform<Derived>::RebuildCXXPseudoDestructorExpr(clang::ASTOwningResult<&clang::ActionBase::DeleteExpr>, clang::SourceLocation, bool, clang::NestedNameSpecifier*, clang::SourceRange, clang::TypeSourceInfo*, clang::SourceLocation, clang::SourceLocation, clang::PseudoDestructorTypeStorage)':
clang/lib/Sema/TreeTransform.h:5784: error: expected primary-expression before '>' token
clang/lib/Sema/TreeTransform.h:5784: error: expected primary-expression before ')' token
make[4]: *** [clang/lib/Sema/Release/SemaTemplate.o] Error 1
llvm-svn: 97136
|
| |
|
|
|
|
|
|
|
| |
class types, dependent types, and namespaces. I had previously
weakened this invariant while working on parsing pseudo-destructor
expressions, but recent work in that area has made these changes
unnecessary.
llvm-svn: 97112
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expressions that look like pseudo-destructors, e.g.,
p->T::~T()
where p has dependent type.
At template instantiate time, we determine whether we actually have a
pseudo-destructor or a member access, and funnel down to the
appropriate routine in Sema.
Fixes PR6380.
llvm-svn: 97092
|
| |
|
|
| |
llvm-svn: 97080
|
| |
|
|
|
|
|
|
|
|
|
| |
CXXPseudoDestructorExpr.
Update template instantiation for pseudo-destructor expressions to use
this source information and to make use of
Sema::BuildPseudoDestructorExpr when the base expression is dependent
or refers to a scalar type.
llvm-svn: 97079
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
destructor calls, e.g.,
p->T::~T
We now detect when the member access that we've parsed, e.g.,
p-> or x.
may be a pseudo-destructor expression, either because the type of p or
x is a scalar or because it is dependent (and, therefore, may become a
scalar at template instantiation time).
We then parse the pseudo-destructor grammar specifically:
::[opt] nested-name-specifier[opt] type-name :: ∼ type-name
and hand those results to a new action, ActOnPseudoDestructorExpr,
which will cope with both dependent member accesses of destructors and
with pseudo-destructor expressions.
This commit affects the parsing of pseudo-destructors, only; the
semantic actions still go through the semantic actions for member
access expressions. That will change soon.
llvm-svn: 97045
|
| |
|
|
|
|
|
|
|
|
|
|
| |
nested-name-specifier, e.g.,
typedef int Int;
int *p;
p->Int::~Int();
This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression.
llvm-svn: 96743
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
now cope with the destruction of types named as dependent templates,
e.g.,
y->template Y<T>::~Y()
Nominally, we implement C++0x [basic.lookup.qual]p6. However, we don't
follow the letter of the standard here because that would fail to
parse
template<typename T, typename U>
X0<T, U>::~X0() { }
properly. The problem is captured in core issue 339, which gives some
(but not enough!) guidance. I expect to revisit this code when the
resolution of 339 is clear, and/or we start capturing better source
information for DeclarationNames.
Fixes PR6152.
llvm-svn: 96367
|
| |
|
|
|
|
|
|
|
| |
rebuilding a typename type terminating in a template-id (with
dependent template name, naturally) as a TypenameType when, because
its context could be fully resolved, we should have been building it
as a QualifiedNameType. Fixes PR6268.
llvm-svn: 96084
|
| |
|
|
|
|
| |
glaring logic bug anyways. =D
llvm-svn: 95533
|
| |
|
|
| |
llvm-svn: 95335
|
| |
|
|
|
|
|
|
| |
realize that CXXConstructExpr is always implicit, so we should just
return its argument (if there is only one) rather than directly
invoking the constructor.
llvm-svn: 95192
|
| |
|
|
|
|
| |
appropriately. Call out a few missing cases in the expression mangler.
llvm-svn: 95176
|
| |
|
|
| |
llvm-svn: 94925
|
| |
|
|
| |
llvm-svn: 94920
|
| |
|
|
| |
llvm-svn: 94791
|