redeclaration chains: only ever have the reader search for
redeclarations of the first (canonical) declaration, since we only
ever record redeclaration ranges for the that declaration. Searching
for redeclarations of non-canonical declarations will never find
anything, so it's a complete waste of time.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147055 91177308-0d34-0410-b5e6-96231b3b80d8
with a definition pointer (e.g., C++ and Objective-C classes), zip
through the redeclaration chain to make sure that all of the
declarations point to the definition data.
As part of this, realized again why the first redeclaration of an
entity in a file is important, and brought back that idea.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146886 91177308-0d34-0410-b5e6-96231b3b80d8
redeclaration templates (RedeclarableTemplateDecl), similarly to the
way (de-)serialization is implemented for Redeclarable<T>. In the
process, found a simpler formulation for handling redeclaration
chains and implemented that in both places.
The new test establishes that we're building the redeclaration chains
properly. However, the FIXME indicates where we're tickling a
different bug that has to do with us not setting the DefinitionData
pointer properly in redeclarations that we detected after the
definition itself was deserialized. The (separable) fix for that bug
is forthcoming.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146883 91177308-0d34-0410-b5e6-96231b3b80d8
which there are no redeclarations. This reduced by size of the PCH
file for Cocoa.h by ~650k: ~536k of that was in the new
LOCAL_REDECLARATIONS table, which went from a ridiculous 540k down to
an acceptable 3.5k, while the rest was due to the more compact
abbreviated representation of redeclarable declaration kinds (which no
longer need to store the 'first' declaration ID).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146869 91177308-0d34-0410-b5e6-96231b3b80d8
variable is initialized by a non-constant expression, and pass in the variable
being declared so that earlier-initialized fields' values can be used.
Rearrange VarDecl init evaluation to make this possible, and in so doing fix a
long-standing issue in our C++ constant expression handling, where we would
mishandle cases like:
extern const int a;
const int n = a;
const int a = 5;
int arr[n];
Here, n is not initialized by a constant expression, so can't be used in an ICE,
even though the initialization expression would be an ICE if it appeared later
in the TU. This requires computing whether the initializer is an ICE eagerly,
and saving that information in PCH files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146856 91177308-0d34-0410-b5e6-96231b3b80d8
chains. The previous implementation relied heavily on the declaration
chain being stored as a (circular) linked list on disk, as it is in
memory. However, when deserializing from multiple modules, the
different chains could get mixed up, leading to broken declaration chains.
The new solution keeps track of the first and last declarations in the
chain for each module file. When we load a declaration, we search all
of the module files for redeclarations of that declaration, then
splice together all of the lists into a coherent whole (along with any
redeclarations that were actually parsed).
As a drive-by fix, (de-)serialize the redeclaration chains of
TypedefNameDecls, which had somehow gotten missed previously. Add a
test of this serialization.
This new scheme creates a redeclaration table that is fairly large in
the PCH file (on the order of 400k for Cocoa.h's 12MB PCH file). The
table is mmap'd in and searched via a binary search, but it's still
quite large. A future tweak will eliminate entries for declarations
that have no redeclarations anywhere, and should
drastically reduce the size of this table.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146841 91177308-0d34-0410-b5e6-96231b3b80d8
applies to an actual definition. Plus, clarify the purpose of this
field and give the accessor a different name, since getLocEnd() is
supposed to be the same as getSourceRange().getEnd().
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146694 91177308-0d34-0410-b5e6-96231b3b80d8
declarations and definitions) as ObjCInterfaceDecls within the same
redeclaration chain. This new representation matches what we do for
C/C++ variables/functions/classes/templates/etc., and makes it
possible to answer the query "where are all of the declarations of
this class?"
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146679 91177308-0d34-0410-b5e6-96231b3b80d8
redeclaration chain for Objective-C classes, including:
- Using the first declaration as the canonical declaration.
- Using the definition as the primary DeclContext
- Making sure that all declarations have a pointer to the definition
data, and the definition knows that it is the definition.
- Serialization support for when a definition gets added to a
declaration that comes from an AST file.
However, note that we're not taking advantage of much of this code
yet, because we're still re-using ObjCInterfaceDecls.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146667 91177308-0d34-0410-b5e6-96231b3b80d8
separately-allocated DefinitionData structure, which we manage the
same way as CXXRecordDecl::DefinitionData. This prepares the way for
making ObjCInterfaceDecls redeclarable, to more accurately model
forward declarations of Objective-C classes and eliminate the mutation
of ObjCInterfaceDecl that causes us serious trouble in the AST reader.
Note that ObjCInterfaceDecl's accessors are fairly robust against
being applied to forward declarations, because Clang (and Sema in
particular) doesn't perform RequireCompleteType/hasDefinition() checks
everywhere it has to. Each of these overly-robust cases is marked with
a FIXME, which we can tackle over time.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146644 91177308-0d34-0410-b5e6-96231b3b80d8
library, since modules cut across all of the libraries. Rename
serialization::Module to serialization::ModuleFile to side-step the
annoying naming conflict. Prune a bunch of ModuleMap.h includes that
are no longer needed (most files only needed the Module type).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145538 91177308-0d34-0410-b5e6-96231b3b80d8
inside an objc container that "contains" other file-level declarations.
When getting the array of file-level declarations that overlap with a file region,
we failed to report that the region overlaps with an objc container, if
the container had other file-level declarations declared lexically inside it.
Fix this by marking such declarations as "isTopLevelDeclInObjCContainer" in the AST
and handling them appropriately.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145109 91177308-0d34-0410-b5e6-96231b3b80d8
it is going to be rewritten (and the chain will be serialized again), otherwise we may form a cycle in its
categories list when deserializing.
Also introduce ASTMutationListener::CompletedObjCForwardRef to notify that a forward reference
was completed; using Decl's isChangedSinceDeserialization/setChangedSinceDeserialization
is bug inducing and kinda gross, we should phase it out.
Fixes infinite loop in rdar://10418538.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144465 91177308-0d34-0410-b5e6-96231b3b80d8
of decl bit offsets.
This allows us to easily get at the location of a decl without deserializing it.
It increases size of Cocoa PCH by only 0.2%.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143123 91177308-0d34-0410-b5e6-96231b3b80d8
essence, the redeclaration chain for a class could end up in an
inconsistent state while deserializing multiple declarations in that
chain, where the circular linked list was not, in fact,
circular. Since only two redeclarations of the same entity will get
loaded when we're in this state, restore circularity when both have
been loaded. Fixes <rdar://problem/10324940> / PR11195.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143037 91177308-0d34-0410-b5e6-96231b3b80d8
-Add the location of the class name to all objc container decls, not just ObjCInterfaceDecl.
-Make objc decls consistent with the rest of the NamedDecls and have getLocation() point to the
class name, not the location of '@'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141061 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of always storing all source locations for the selector identifiers
we check whether all the identifiers are in a "standard" position; "standard" position is
-Immediately before the arguments: -(id)first:(int)x second:(int)y;
-With a space between the arguments: -(id)first: (int)x second: (int)y;
-For nullary selectors, immediately before ';': -(void)release;
In such cases we infer the locations instead of storing them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140989 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139644 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139441 91177308-0d34-0410-b5e6-96231b3b80d8
ASTContext reference. Remove all of the extra checking and logic that
was used to cope with a NULL ASTContext. No effective functionality
change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139413 91177308-0d34-0410-b5e6-96231b3b80d8
The initial incentive was to fix a crash when PCH chaining categories
to an interface, but the fix was done in the "modules way" that I hear
is popular with the kids these days.
Each module stores the local chain of categories and we combine them
when the interface is loaded. We also warn if non-dependent modules
introduce duplicate named categories.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138926 91177308-0d34-0410-b5e6-96231b3b80d8
Remove
-setClassInterface
-setNextClassCategory
-insertNextClassCategory
and combine them in the Create function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138817 91177308-0d34-0410-b5e6-96231b3b80d8
, 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138709 91177308-0d34-0410-b5e6-96231b3b80d8
redeclarations of a particular entity would occur in source
order. Friend declarations that occur within class templates (or
member classes thereof) do not follow this, nor would modules. Big
thanks to Erik Verbruggen for reducing this problem from the Very
Large Qt preamble testcase he found.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138557 91177308-0d34-0410-b5e6-96231b3b80d8
module DAG-based lookup scheme. This required some reshuffling, so
that each module stores its own mapping from DeclContexts to their
lexical and visible sets for those DeclContexts (rather than one big
"chain").
Overall, this allows simple qualified name lookup into the translation
unit to gather results from multiple modules, with the lookup results
in module B shadowing the lookup results in module A when B imports A.
Walking all of the lexical declarations in a module DAG is still a
mess; we'll end up walking the loaded module list backwards, which
works fine for chained PCH but doesn't make sense in a DAG. I'll
tackle this issue as a separate commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138463 91177308-0d34-0410-b5e6-96231b3b80d8
Example:
template <class T>
class A {
public:
template <class U> void f(U p) { }
template <> void f(int p) { } // <== class scope specialization
};
This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code.
BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137573 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137395 91177308-0d34-0410-b5e6-96231b3b80d8
IDs will never cross module boundaries, since they're tied to the
CXXDefinitionData, so just use a local mapping throughout. Eliminate
the global -> local tables and supporting data.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136847 91177308-0d34-0410-b5e6-96231b3b80d8
reader, to allow AST files to be loaded with their declarations
remapped to different ID numbers. Fix a number of places where we were
either failing to map local declaration IDs into global declaration
IDs or where interpreting the local declaration IDs within the wrong
module.
I've tested this via the usual "random gaps" method. It works well
except for the preamble tests, because our handling of the precompiled
preamble requires declaration and preprocessed entity to be stable
when parsing code and then loading that back into memory. This
property will hold in general, but my randomized testing naturally
breaks this property to get more coverage. In the future, I expect
that the precompiled preamble logic won't need this property.
I am very unhappy with the current handling of the translation unit,
which is a rather egregious hack. We're going to have to do something
very different here for loading multiple AST files, because we don't
want to have to cope with merging two translation units. Likely, we'll
just handle translation units entirely via "update" records, and
predefine a single, fixed declaration ID for the translation
unit. That will come later.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136779 91177308-0d34-0410-b5e6-96231b3b80d8
were (Module*, Offset) with equivalent maps whose value type is just a
Module*. The offsets have moved into corresponding "Base" fields
within the Module itself, where they will also be helpful for
local->global translation (eventually).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136441 91177308-0d34-0410-b5e6-96231b3b80d8
so that we have one, simple way to map from global bit offsets to
local bit offsets. Eliminates a number of loops over the chain, and
generalizes for more interesting bit remappings.
Also, as an amusing oddity, we were computing global bit offsets
*backwards* for preprocessed entities (e.g., the directly included PCH
file in the chain would start at offset zero, rather than the original
PCH that occurs first in translation unit). Even more amusingly, it
made precompiled preambles work, because we were forgetting to adjust
the local bit offset to a global bit offset when storing preprocessed
entity offsets in the ASTUnit. Two wrongs made a right, and now
they're both right.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135750 91177308-0d34-0410-b5e6-96231b3b80d8
type IDs into a single place, and make sure that all of the callers
use the appropriate functions to do the mapping. Since the mapping is
still the identity function, this is essentially a no-op.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135733 91177308-0d34-0410-b5e6-96231b3b80d8
such that every declaration ID loaded from an AST file will go through
a central local -> global mapping function. At present, this change
does nothing, since the local -> global mapping function is the
identity function.
This is the mechanical part of the refactoring; a follow-up patch will
address a few remaining areas where it's not obvious whether we're
dealing with local or global IDs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135711 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135548 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133243 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132868 91177308-0d34-0410-b5e6-96231b3b80d8
constant, also consider whether it's a class type that has any mutable
fields. If so, it can't be a global constant.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131276 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131101 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131013 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130669 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130628 91177308-0d34-0410-b5e6-96231b3b80d8
based on Doug's preferences when we discussed this in IRC. This brings
the wording more in line with the standard.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130603 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130601 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130076 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129794 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127056 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127004 91177308-0d34-0410-b5e6-96231b3b80d8
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)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126459 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125771 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125733 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125434 91177308-0d34-0410-b5e6-96231b3b80d8
Also, reorganize and make very explicit the logic for determining
the value kind and type of a referenced declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125150 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125005 91177308-0d34-0410-b5e6-96231b3b80d8
Inheritable attributes on declarations may be inherited by any later
redeclaration at merge time. By contrast, a non-inheritable attribute
will not be inherited by later redeclarations. Non-inheritable
attributes may be semantically analysed early, allowing them to
influence the redeclaration/overloading process.
Before this change, the "overloadable" attribute received special
handling to be treated as non-inheritable, while all other attributes
were treated as inheritable. This patch generalises the concept,
while removing a FIXME. Some CUDA location attributes are also marked
as non-inheritable in order to support special overloading semantics
(to be introduced in a later patch).
The patch introduces a new Attr subclass, InheritableAttr, from
which all inheritable attributes derive. Non-inheritable attributes
simply derive from Attr.
N.B. I did not review every attribute to determine whether it should
be marked non-inheritable. This can be done later on an incremental
basis, as this change does not affect default functionality.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123959 91177308-0d34-0410-b5e6-96231b3b80d8
a pack expansion, e.g., the parameter pack Values in:
template<typename ...Types>
struct Outer {
template<Types ...Values>
struct Inner;
};
This new implementation approach introduces the notion of an
"expanded" non-type template parameter pack, for which we have already
expanded the types of the parameter pack (to, say, "int*, float*",
for Outer<int*, float*>) but have not yet expanded the values. Aside
from creating these expanded non-type template parameter packs, this
patch updates template argument checking and non-type template
parameter pack instantiation to make use of the appropriate types in
the parameter pack.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123845 91177308-0d34-0410-b5e6-96231b3b80d8
FunctionDecl::setPure crashed a poor user's code.
Remove the use of this accessor when deserializing, along with several other in the neighborhood. Fixes rdar://8759653.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122756 91177308-0d34-0410-b5e6-96231b3b80d8
packs, e.g.,
template<typename T, unsigned ...Dims> struct multi_array;
along with semantic analysis support for finding unexpanded non-type
template parameter packs in types, expressions, and so on.
Template instantiation involving non-type template parameter packs
probably doesn't work yet. That'll come soon.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122527 91177308-0d34-0410-b5e6-96231b3b80d8
common base for ExtQuals and Type that stores the underlying type
pointer. This results in a 2% performance win for -emit-llvm on a
typical C file, with 1% memory growth in the AST.
Note that there is an API change in this optimization:
QualType::getTypePtr() can no longer be invoked on a NULL
QualType. If the QualType might be NULL, use
QualType::getTypePtrOrNull(). I've audited all uses of getTypePtr() in
the code base and changed the appropriate uses over to
getTypePtrOrNull().
A future optimization opportunity would be to distinguish between
cast/dyn_cast and cast_or_null/dyn_cast_or_null; for the former, we
could use getTypePtr() rather than getTypePtrOrNull(), to take another
branch out of the cast/dyn_cast implementation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@121489 91177308-0d34-0410-b5e6-96231b3b80d8
"inline", we weren't giving the definition weak linkage because the
"inline" bit wasn't propagated. This was a longstanding FIXME that,
somehow, hadn't triggered a bug in the wild. Fix this problem by
tracking whether any declaration was marked "inline", and clean up the
semantics of GNU's "extern inline" semantics calculation based on this
change.
Fixes <rdar://problem/8740363>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@121373 91177308-0d34-0410-b5e6-96231b3b80d8
My previous attempt at solving the compile-time problem with many
redeclarations of the same entity cached both linkage and visibility,
while this patch only tackles linkage. There are several reasons for
this difference:
- Linkage is a language concept, and is evaluated many times during
semantic analysis and codegen, while visibility is only a
code-generation concept that is evaluated only once per (unique)
declaration. Hence, we *must* optimize linkage calculations but
don't need to optimize visibility computation.
- Once we know the linkage of a declaration, subsequent
redeclarations can't change that linkage. Hence, cache
invalidation is far simpler than for visibility, where a later
redeclaration can completely change the visibility.
- We have 3 spare bits in Decl to store the linkage cache, so the
cache doesn't increase the size of declarations. With the
visibility+linkage cache, NamedDecl got larger.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@121023 91177308-0d34-0410-b5e6-96231b3b80d8
and visibility of declarations, because it was extremely messy and it
increased the size of NamedDecl.
An improved implementation is forthcoming.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@121012 91177308-0d34-0410-b5e6-96231b3b80d8
declarations.
The motivation for this patch is that linkage/visibility computations
are linear in the number of redeclarations of an entity, and we've run
into a case where a single translation unit has > 6500 redeclarations
of the same (unused!) external variable. Since each redeclaration
involves a linkage check, the resulting quadratic behavior makes Clang
slow to a crawl. With this change, a simple test with 512
redeclarations of a variable syntax-checks ~20x faster than
before.
That said, I hate this change, and will probably end up reverting it
in a few hours. Reasons to hate it:
- It makes NamedDecl larger, since we don't have enough free bits in
Decl to squeeze in the extra information about caching.
- There are way too many places where we need to invalidate this
cache, because the visibility of a declaration can change due to
redeclarations (!). Despite self-hosting and passing the testsuite,
I have no confidence that I've found all of places where this cache
needs to be invalidated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120808 91177308-0d34-0410-b5e6-96231b3b80d8
A new AST node is introduced:
def IndirectField : DDecl<Value>;
IndirectFields are injected into the anonymous's parent scope and chain back to
the original field. Name lookup for anonymous entities now result in an
IndirectFieldDecl instead of a FieldDecl.
There is no functionality change, the code generated should be the same.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119919 91177308-0d34-0410-b5e6-96231b3b80d8
@synthesize foo = _foo;
keep track of the location of the ivar ("_foo"). Teach libclang to
visit the ivar as a member reference.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119447 91177308-0d34-0410-b5e6-96231b3b80d8
abstractions (e.g., TemplateArgumentListBuilder) that were designed to
support variadic templates. Only a few remnants of variadic templates
remain, in the parser (parsing template type parameter packs), AST
(template type parameter pack bits and TemplateArgument::Pack), and
Sema; these are expected to be used in a future implementation of
variadic templates.
But don't get too excited about that happening now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118385 91177308-0d34-0410-b5e6-96231b3b80d8
In that case a chained PCH will record the updates to the DefinitionData pointer of forward references.
If a forward reference mutated into a definition re-write it into the chained PCH, this is too big of a change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117239 91177308-0d34-0410-b5e6-96231b3b80d8
- Pass around RecordDataImpl instead of the concrete RecordData so that any SmallVector can be used.
- Move ASTDeclWriter::WriteCXXDefinitionData to ASTWriter::AddCXXDefinitionData.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117236 91177308-0d34-0410-b5e6-96231b3b80d8
its initial creation/deserialization and store the changes in a chained PCH.
The idea is that the AST entities call methods on the ASTMutationListener to give notifications
of changes; the PCHWriter implements the ASTMutationListener interface and stores the incremental changes
of the updated entity. WIP
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117235 91177308-0d34-0410-b5e6-96231b3b80d8
by marking the decl invalid isn't. Make some steps towards supporting these
and then hastily shut them down at the last second by marking them as
unsupported.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116661 91177308-0d34-0410-b5e6-96231b3b80d8
already be determined by isCopyAssignmentOperator(), and was set too
late in the process for all clients to see the appropriate
value. Cleanup only; no functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114916 91177308-0d34-0410-b5e6-96231b3b80d8
The canonical FunctionTemplateDecl contains the specializations but we cannot use getCanonicalDecl on Template because it may still be initializing.
Write and read it from PCH.
Fixes http://llvm.org/PR8134
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113744 91177308-0d34-0410-b5e6-96231b3b80d8
Another beating by boost in this test case: http://llvm.org/PR8117
A function specialization wasn't properly initialized if it wasn't canonical.
I wish there was a nice little test case but this was boost.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113481 91177308-0d34-0410-b5e6-96231b3b80d8
PCH got a severe beating by the boost-using test case reported here: http://llvm.org/PR8099
Fix issues like:
-When PCH reading, make sure Decl's getASTContext() doesn't get called since a Decl in the parent hierarchy may be initializing.
-In ASTDeclReader::VisitFunctionDecl VisitRedeclarable should be called before using FunctionDecl's isCanonicalDecl()
-In ASTDeclReader::VisitRedeclarableTemplateDecl CommonOrPrev must be initialized before anything else.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113391 91177308-0d34-0410-b5e6-96231b3b80d8
three different kinds of AST nodes to represent using declarations:
UsingDecl, UnresolvedUsingValueDecl, and
UnresolvedUsingTypenameDecl. These three are collapsed into a single
cursor kind for using declarations, since libclang clients don't need
the distinction.
Several related changes here:
- Cursor visitation of the three AST nodes for using declarations
- Proper source-range computation for these AST nodes
- Using declarations have no USRs, since they don't actually declare
any entities.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112730 91177308-0d34-0410-b5e6-96231b3b80d8
suppressing USRs). Also, fix up the source location information for
using directives so that the declaration location refers to the
namespace name.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112693 91177308-0d34-0410-b5e6-96231b3b80d8
(and thus protocol_begin(), protocol_end()) now only contains the list of protocols that were directly referenced in
an @interface declaration. 'all_referenced_protocol_[begin,end]()' now returns the set of protocols that were referenced
in both the @interface and class extensions. The latter is needed for semantic analysis/codegen, while the former is
needed to maintain the lexical information of the original source.
Fixes <rdar://problem/8380046>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112691 91177308-0d34-0410-b5e6-96231b3b80d8
aliases. Previously, the location of the alias was at the "namespace"
keyword. Now, it's on the identifier being declared (as is the custom
for Clang), and we keep a separate source location for the "namespace"
keyword.
Also, added a getSourceRange() member function to NamespaceAliasDecl
to correctly compute the source range.
Finally, removed a bunch of setters from NamespaceAliasDecl and gave
ASTReaderDecl friendship so that it could set the corresponding fields
directly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112681 91177308-0d34-0410-b5e6-96231b3b80d8
over ivars for a varienty of puposes is now
consolidated into two small routines; DeepCollectObjCIvars
and ShallowCollectObjCIvars.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111679 91177308-0d34-0410-b5e6-96231b3b80d8
*Huge* improvement over the amount of deserializing that we do for C++ lookup.
e.g, if he have the Carbon header precompiled and include it on a file containing this:
int x;
these are the before/after stats:
BEFORE:
*** AST File Statistics:
578 stat cache hits
4 stat cache misses
548/30654 source location entries read (1.787695%)
15907/16501 types read (96.400223%)
53525/59955 declarations read (89.275291%)
33993/43525 identifiers read (78.099945%)
41516/51891 statements read (80.006165%)
77/5317 macros read (1.448185%)
0/6335 lexical declcontexts read (0.000000%)
1/5424 visible declcontexts read (0.018437%)
AFTER using the on-disk table:
*** AST File Statistics:
578 stat cache hits
4 stat cache misses
548/30654 source location entries read (1.787695%)
10/16501 types read (0.060602%)
9/59955 declarations read (0.015011%)
161/43525 identifiers read (0.369902%)
20/51891 statements read (0.038542%)
6/5317 macros read (0.112846%)
0/6335 lexical declcontexts read (0.000000%)
2/5424 visible declcontexts read (0.036873%)
There's only one issue affecting mostly the precompiled preambles which I will address soon.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111636 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor