to the consumer without being fully deserialized).
The regression was on compiling boost.python and it was too difficult to get a reduced
test case unfortunately.
Also modify the logic of how objc methods are getting passed to the consumer;
codegen depended on receiving objc methods before the implementation decl.
Since the interesting objc methods are ones with a body and such methods only
exist inside an ObjCImplDecl, deserialize and pass to consumer all the methods
of ObCImplDecl when we see one.
Fixes http://llvm.org/PR10922 & rdar://10117105.
llvm-svn: 139644
than having CodeGen check whether a declaration comes from an AST file
(which it shouldn't know or care about), make sure that the AST writer and
reader pass along "interesting" declarations that CodeGen needs to
know about.
llvm-svn: 139441
declaration was deserialized from an AST file. Use this instead of
Decl::getPCHLevel() wherever possible. This is a simple step toward
killing off Decl::getPCHLevel().
llvm-svn: 139427
, such as list of forward @class decls, in a DeclGroup
node. Deal with its consequence throught clang. This
is in preparation for more Sema work ahead. // rdar://8843851.
Feel free to reverse if it breaks something important
and I am unavailable.
llvm-svn: 138709
declaration that never actually gets serialized. Instead, serialize
the various kinds of update records (lexical decls, visible decls, the
addition of an anonymous namespace) for the translation unit, even if
we're not chaining. This way, we won't have to deal with multiple
loaded translation unit declarations.
llvm-svn: 137395
type/expression/template argument/etc. is instantiation-dependent if
it somehow involves a template parameter, even if it doesn't meet the
requirements for the more common kinds of dependence (dependent type,
type-dependent expression, value-dependent expression).
When we see an instantiation-dependent type, we know we always need to
perform substitution into that instantiation-dependent type. This
keeps us from short-circuiting evaluation in places where we
shouldn't, and lets us properly implement C++0x [temp.type]p2.
In theory, this would also allow us to properly mangle
instantiation-dependent-but-not-dependent decltype types per the
Itanium C++ ABI, but we aren't quite there because we still mangle
based on the canonical type in cases like, e.g.,
template<unsigned> struct A { };
template<typename T>
void f(A<sizeof(sizeof(decltype(T() + T())))>) { }
template void f<int>(A<sizeof(sizeof(int))>);
and therefore get the wrong answer.
llvm-svn: 134225
they should still be officially __strong for the purposes of errors,
block capture, etc. Make a new bit on variables, isARCPseudoStrong(),
and set this for 'self' and these enumeration-loop variables. Change
the code that was looking for the old patterns to look for this bit,
and change IR generation to find this bit and treat the resulting
variable as __unsafe_unretained for the purposes of init/destroy in
the two places it can come up.
llvm-svn: 133243
Related result types apply Cocoa conventions to the type of message
sends and property accesses to Objective-C methods that are known to
always return objects whose type is the same as the type of the
receiving class (or a subclass thereof), such as +alloc and
-init. This tightens up static type safety for Objective-C, so that we
now diagnose mistakes like this:
t.m:4:10: warning: incompatible pointer types initializing 'NSSet *'
with an
expression of type 'NSArray *' [-Wincompatible-pointer-types]
NSSet *array = [[NSArray alloc] init];
^ ~~~~~~~~~~~~~~~~~~~~~~
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:72:1:
note:
instance method 'init' is assumed to return an instance of its
receiver
type ('NSArray *')
- (id)init;
^
It also means that we get decent type inference when writing code in
Objective-C++0x:
auto array = [[NSMutableArray alloc] initWithObjects:@"one", @"two",nil];
// ^ now infers NSMutableArray* rather than id
llvm-svn: 132868
- New isDefined() function checks for deletedness
- isThisDeclarationADefinition checks for deletedness
- New doesThisDeclarationHaveABody() does what
isThisDeclarationADefinition() used to do
- The IsDeleted bit is not propagated across redeclarations
- isDeleted() now checks the canoncial declaration
- New isDeletedAsWritten() does what it says on the tin.
- isUserProvided() now correct (thanks Richard!)
This fixes the bug that we weren't catching
void foo() = delete;
void foo() {}
as being a redefinition.
llvm-svn: 131013
parameter node and use this to correctly mangle parameter
references in function template signatures.
A follow-up patch will improve the storage usage of these
fields; here I've just done the lazy thing.
llvm-svn: 130669
accompanying fixes to make it work today.
The core of this patch is to provide a link from a TemplateTypeParmType
back to the TemplateTypeParmDecl node which declared it. This in turn
provides much more precise information about the type, where it came
from, and how it functions for AST consumers.
To make the patch work almost a year after its first attempt, it needed
serialization support, and it now retains the old getName() interface.
Finally, it requires us to not attempt to instantiate the type in an
unsupported friend decl -- specifically those coming from template
friend decls but which refer to a specific type through a dependent
name.
A cleaner representation of the last item would be to build
FriendTemplateDecl nodes for these, storing their template parameters
etc, and to perform proper instantation of them like any other template
declaration. They can still be flagged as unsupported for the purpose of
access checking, etc.
This passed an asserts-enabled bootstrap for me, and the reduced test
case mentioned in the original review thread no longer causes issues,
likely fixed at somewhere amidst the 24k revisions that have elapsed.
llvm-svn: 130628
gcc's unused warnings which don't get emitted if the function is referenced even in an unevaluated context
(e.g. in templates, sizeof, etc.). Also, saying that a function is 'unused' because it won't get codegen'ed
is somewhat misleading.
- Don't emit 'unused' warnings for functions that are referenced in any part of the user's code.
- A warning that an internal function/variable won't get emitted is useful though, so introduce
-Wunneeded-internal-declaration which will warn if a function/variable with internal linkage is not
"needed" ('used' from the codegen perspective), e.g:
static void foo() { }
template <int>
void bar() {
foo();
}
test.cpp:1:13: warning: function 'foo' is not needed and will not be emitted
static void foo() { }
^
Addresses rdar://8733476.
llvm-svn: 129794
UnresolvedUsingValueDecl to use NestedNameSpecifierLoc rather than the
extremely-lossy NestedNameSpecifier/SourceRange pair it used to use,
improving source-location information.
Various infrastructure updates to support NestedNameSpecifierLoc:
- AST/PCH (de-)serialization
- Recursive AST visitor
- libclang traversal (including the first tests of this
functionality)
llvm-svn: 126459
making them be template instantiated in a more normal way and
make them handle attributes like other decls.
This fixes the used/unused label handling stuff, making it use
the same infrastructure as other decls.
llvm-svn: 125771
LabelDecl and LabelStmt. There is a 1-1 correspondence between the
two, but this simplifies a bunch of code by itself. This is because
labels are the only place where we previously had references to random
other statements, causing grief for AST serialization and other stuff.
This does cause one regression (attr(unused) doesn't silence unused
label warnings) which I'll address next.
This does fix some minor bugs:
1. "The only valid attribute " diagnostic was capitalized.
2. Various diagnostics printed as ''labelname'' instead of 'labelname'
3. This reduces duplication of label checking between functions and blocks.
Review appreciated, particularly for the cindex and template bits.
llvm-svn: 125733
Temporarily set the first (canonical) declaration as the previous one, which is the one that
matters, and mark the real previous DeclID to be loaded & attached later on.
Fixes rdar://8956193.
llvm-svn: 125434
- BlockDeclRefExprs always store VarDecls
- BDREs no longer store copy expressions
- BlockDecls now store a list of captured variables, information about
how they're captured, and a copy expression if necessary
With that in hand, change IR generation to use the captures data in
blocks instead of walking the block independently.
Additionally, optimize block layout by emitting fields in descending
alignment order, with a heuristic for filling in words when alignment
of the end of the block header is insufficient for the most aligned
field.
llvm-svn: 125005
Argyrios Kyrtzidis