AST reader down to the AST file + local ID within that file, rather
than lamely walking the PCH chain. There's no actual functionality
change now, but this is cleaner and more general.
llvm-svn: 135548
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
hasTrivialDefaultConstructor() really really means it now.
Also implement a fun standards bug regarding aggregates. Doug, if you'd
like, I can un-implement that bug if you think it is truly a defect.
The bug is that non-special-member constructors are never considered
user-provided, so the following is an aggregate:
struct foo {
foo(int);
};
It's kind of bad, but the solution isn't obvious - should
struct foo {
foo (int) = delete;
};
be an aggregate or not?
Lastly, add a missing initialization to FunctionDecl.
llvm-svn: 131101
- 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
type trait. The previous implementation suffered from several problems:
1) It implemented all of the logic in RecordType by walking over every
base and field in a CXXRecordDecl and validating the constraints of
the standard. This made for very straightforward code, but is
extremely inefficient. It also is conceptually wrong, the logic tied
to the C++ definition of standard-layout classes should be in
CXXRecordDecl, not RecordType.
2) To address the performance problems with #1, a cache bit was added to
CXXRecordDecl, and at the completion of every C++ class, the
RecordType was queried to determine if it was a standard layout
class, and that state was cached. Two things went very very wrong
with this. First, the caching version of the query *was never
called*. Even within the recursive steps of the walk over all fields
and bases the caching variant was not called, making each query
a full *recursive* walk. Second, despite the cache not being used, it
was computed for every class declared, even when the trait was never
used in the program. This probably significantly regressed compile
time performance for edge-case files.
3) An ASTContext was required merely to query the type trait because
querying it performed the actual computations.
4) The caching bit wasn't managed correctly (uninitialized).
The new implementation follows the system for all the other traits on
C++ classes by encoding all the state needed in the definition data and
building up the trait incrementally as each base and member are added to
the definition of the class.
The idiosyncracies of the specification of standard-layout classes
requires more state than I would like; currently 5 bits. I could
eliminate one of the bits easily at the expense of both clarity and
resilience of the code. I might be able to eliminate one of the other
bits by computing its state in terms of other state bits in the
definition. I've already done that in one place where there was a fairly
simple way to achieve it.
It's possible some of the bits could be moved out of the definition data
and into some other structure which isn't serialized if the serialized
bloat is a problem. That would preclude serialization of a partial class
declaration, but that's likely already precluded.
Comments on any of these issues welcome.
llvm-svn: 130601
operators in C++ record declarations.
This patch starts off by updating a bunch of the standard citations to
refer to the draft 0x standard so that the semantics intended for move
varianst is clear. Where necessary these are duplicated so they'll be
available in doxygen.
It adds bit fields to keep track of the state for the move constructs,
and updates all the code necessary to track this state (I think) as
members are declared for a class. It also wires the state into the
various trait-like accessors in the AST's API, and tests that the type
trait expressions now behave correctly in the presence of move
constructors and move assignment operators.
This isn't complete yet due to these glaring FIXMEs:
1) No synthesis of implicit move constructors or assignment operators.
2) I don't think we correctly enforce the new logic for both copy and
move trivial checks: that the *selected* copy/move
constructor/operator is trivial. Currently this requires *all* of them
to be trivial.
3) Some of the trait logic needs to be folded into the fine-grained
trivial bits to more closely match the wording of the standard. For
example, many of the places we currently set a bit to track POD-ness
could be removed by querying other more fine grained traits on
demand.
llvm-svn: 130076
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
use the translation unit as its declaration context, then deserialize
the actual lexical and semantic DeclContexts after the template
parameter is complete. This avoids problems when the DeclContext
itself (e.g., a class template) is dependent on the template parameter
(e.g., for the injected-class-name).
llvm-svn: 127056
DeclContext once we've created it. This mirrors what we do for
function parameters, where the parameters start out with
translation-unit context and then are adopted by the appropriate
DeclContext when it is created. Also give template parameters public
access and make sure that they don't show up for the purposes of name
lookup.
Fixes PR9400, a regression introduced by r126920, which implemented
substitution of default template arguments provided in template
template parameters (C++ core issue 150).
How on earth could the DeclContext of a template parameter affect the
handling of default template arguments?
I'm so glad you asked! The link is
Sema::getTemplateInstantiationArgs(), which determines the outer
template argument lists that correspond to a given declaration. When
we're instantiating a default template argument for a template
template parameter within the body of a template definition (not it's
instantiation, per core issue 150), we weren't getting any outer
template arguments because the context of the template template
parameter was the translation unit. Now that the context of the
template template parameter is its owning template, we get the
template arguments from the injected-class-name of the owning
template, so substitution works as it should.
llvm-svn: 127004
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
Douglas Gregor