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
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.
llvm-svn: 123959
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.
llvm-svn: 123845
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.
llvm-svn: 122756
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.
llvm-svn: 122527
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.
llvm-svn: 121489
"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>.
llvm-svn: 121373
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.
llvm-svn: 121023
and visibility of declarations, because it was extremely messy and it
increased the size of NamedDecl.
An improved implementation is forthcoming.
llvm-svn: 121012
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.
llvm-svn: 120808
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.
llvm-svn: 119919
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.
llvm-svn: 118385
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.
llvm-svn: 117239
- Pass around RecordDataImpl instead of the concrete RecordData so that any SmallVector can be used.
- Move ASTDeclWriter::WriteCXXDefinitionData to ASTWriter::AddCXXDefinitionData.
llvm-svn: 117236
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
llvm-svn: 117235
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.
llvm-svn: 116661
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.
llvm-svn: 114916
Chris Lattner