| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 90549
|
| |
|
|
| |
llvm-svn: 90542
|
| |
|
|
| |
llvm-svn: 90521
|
| |
|
|
|
|
| |
don't infinitely recurse for cases we can't evaluate.
llvm-svn: 90480
|
| |
|
|
|
|
|
| |
a new virtual function is declared/instantiated. it is used
in couple of places.
llvm-svn: 90470
|
| |
|
|
| |
llvm-svn: 90441
|
| |
|
|
| |
llvm-svn: 90435
|
| |
|
|
| |
llvm-svn: 90361
|
| |
|
|
|
|
|
| |
constructor, by keeping the DeclaratorInfo* rather than just the type
and a single location.
llvm-svn: 90355
|
| |
|
|
|
|
| |
generated, we mark any virtual implicit member functions as referenced.
llvm-svn: 90327
|
| |
|
|
| |
llvm-svn: 90313
|
| |
|
|
|
|
|
| |
leaked data structure than before. This kills off the last remaining
explicit uses of OverloadedFunctionDecl in Sema.
llvm-svn: 90306
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
ASTContext instead of malloc. Besides reducing malloc traffic, this
also removes a source of memory leaks when using a BumpPtrAllocator
for the allocator of ASTContext. There are still leaks when using
MallocAllocator because Decl::Destroy() isn't fully finished.
Fixes: <rdar://problem/7431556>
llvm-svn: 90174
|
| |
|
|
|
|
| |
fixing a synthetic ctor/dtor bug.
llvm-svn: 90168
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 90153
|
| |
|
|
|
|
| |
recent change to make SEL a builtin type (fixes radar 7425510).
llvm-svn: 90145
|
| |
|
|
| |
llvm-svn: 90137
|
| |
|
|
|
|
| |
functionality change.
llvm-svn: 90078
|
| |
|
|
|
|
|
| |
function names outside of templates - they'll probably cause some damage there as
they're largely untested.
llvm-svn: 90064
|
| |
|
|
| |
llvm-svn: 90043
|
| |
|
|
|
|
| |
structures!
llvm-svn: 90020
|
| |
|
|
|
|
| |
base with whether it's virtual or not.
llvm-svn: 90018
|
| |
|
|
| |
llvm-svn: 89932
|
| |
|
|
|
|
| |
This fixes pr5611.
llvm-svn: 89895
|
| |
|
|
|
|
|
|
|
|
|
| |
the linkage of a declaration. Switch the lame (and completely wrong)
NamedDecl::hasLinkage() over to using the new NamedDecl::getLinkage(),
along with the "can this declaration be a template argument?" check
that started all of this.
Fixes -fsyntax-only for PR5597.
llvm-svn: 89891
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 89782
|
| |
|
|
|
|
|
|
| |
static member constants. No significant visible difference at the moment
because it conservatively assumes the base has side effects. I'm planning to
use this for CodeGen.
llvm-svn: 89738
|
| |
|
|
| |
llvm-svn: 89696
|
| |
|
|
| |
llvm-svn: 89692
|
| |
|
|
|
|
|
| |
objective-c pointer type. This was a serious mishap and
luckily, Ted's test caught that (and patch fixes the test case).
llvm-svn: 89680
|
| |
|
|
|
|
| |
methods. This fixes a crash when writing sizeof(Incomplete&), and lets ASTContext's methods do the right thing for CodeGen, which fixes PR5590.
llvm-svn: 89668
|
| |
|
|
| |
llvm-svn: 89657
|
| |
|
|
|
|
|
| |
their template parameter depth and position, so that we can match
redeclarations appropriately. Fixes PR5527 and PR5528.
llvm-svn: 89654
|
| |
|
|
|
|
| |
DeclRefExprs
llvm-svn: 89649
|
| |
|
|
|
|
|
|
|
|
| |
locations" into
a new class. Use it pervasively throughout Sema.
My fingers hurt.
llvm-svn: 89638
|
| |
|
|
|
|
| |
a byte. This fixes PR5580.
llvm-svn: 89611
|
| |
|
|
| |
llvm-svn: 89604
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
type and fixes a long-standing code gen. crash reported in
at least two PRs and a radar. (radar 7405040 and pr5025).
There are couple of remaining issues that I would like for
Ted. and Doug to look at:
Ted, please look at failure in Analysis/MissingDealloc.m.
I have temporarily added an expected-warning to make the
test pass. This tests has a declaration of 'SEL' type which
may not co-exist with the new changes.
Doug, please look at a FIXME in PCHWriter.cpp/PCHReader.cpp.
I think the changes which I have ifdef'ed out are correct. They
need be considered for in a few Indexer/PCH test cases.
llvm-svn: 89561
|
| |
|
|
| |
llvm-svn: 89552
|
| |
|
|
| |
llvm-svn: 89546
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following attributes are currently supported in C++0x attribute
lists (and in GNU ones as well):
- align() - semantics believed to be conformant to n3000, except for
redeclarations and what entities it may apply to
- final - semantics believed to be conformant to CWG issue 817's proposed
wording, except for redeclarations
- noreturn - semantics believed to be conformant to n3000, except for
redeclarations
- carries_dependency - currently ignored (this is an optimization hint)
llvm-svn: 89543
|
| |
|
|
|
|
|
| |
rather than punting to a DependentSizedArrayType, tightening up our
type checking for template definitions. Thanks, John!
llvm-svn: 89407
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
incomplete array initialization, where we have the following in a
template:
int a[] = { 1, 2, something-value-dependent };
// ...
sizeof(a);
The type of "a" appears to be a non-dependent IncompleteArrayType, but
treating it as such makes the sizeof(a) fail at template definition
time. We now correctly handle this by morphing the IncompleteArrayType
into a DependentSizedArrayType with a NULL expression, indicating that
its size has no corresponding expression (and, therefore, the type is
distinct from others).
llvm-svn: 89366
|
| |
|
|
|
|
|
|
|
|
| |
two classes, one for typenames and one for values; this seems to have some
support from Doug if not necessarily from the extremely-vague-on-this-point
standard. Track the location of the 'typename' keyword in a using-typename
decl. Make a new lookup result for unresolved values and deal with it in
most places.
llvm-svn: 89184
|