| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 126489
|
| |
|
|
|
|
|
| |
tag definitions. Also, add support for template instantiation of
NestedNameSpecifierLocs.
llvm-svn: 126470
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
I tried to add test cases for these, but I can't because variables
aren't warned on the way functions are and the codegen layer appears to
use different logic for determining that 'a' and 'g' in the test case
should receive C mangling. I've included the test so that if we ever
switch the codegen layer to use these functions, we won't regress due to
latent bugs.
llvm-svn: 126453
|
| |
|
|
|
|
|
| |
namespace blanket rule for variables and functions declared 'extern
"C"'.
llvm-svn: 126400
|
| |
|
|
|
|
| |
the stack.
llvm-svn: 126254
|
| |
|
|
|
|
|
|
| |
lead to a serious slowdown (4%) on parsing of Cocoa.h. This memory
optimization should be revisited later, when we have time to look at
the generated code.
llvm-svn: 126033
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
without defining them. This should be an error, but I'm paranoid about
"uses" that end up not actually requiring a definition. I'll revisit later.
Also, teach IR generation to not set internal linkage on variable
declarations, just for safety's sake. Doing so produces an invalid module
if the variable is not ultimately defined.
Also, fix several places in the test suite where we were using internal
functions without definitions.
llvm-svn: 126016
|
| |
|
|
| |
llvm-svn: 125755
|
| |
|
|
| |
llvm-svn: 125754
|
| |
|
|
| |
llvm-svn: 125751
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 125730
|
| |
|
|
|
|
|
| |
linkage into Decl.cpp. Disable this logic for extern "C" functions, because
the operative rule there is weaker. Fixes rdar://problem/8898466
llvm-svn: 125268
|
| |
|
|
| |
llvm-svn: 125104
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
| |
on, as well as more reliably limiting invalid references to locals from
nested scopes.
llvm-svn: 124721
|
| |
|
|
|
|
| |
Part of the fix for PR8413.
llvm-svn: 123904
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
thousand other things which were (generally inadvertantly) relying on that.
llvm-svn: 123814
|
| |
|
|
|
|
|
| |
and mark the fields they use as mutable. This allows us to remove a few
const_casts.
llvm-svn: 123314
|
| |
|
|
|
|
|
|
|
| |
sentence of [temp.deduct.call]p1, both of which concern the
non-deducibility of parameter packs not at the end of a
parameter-type-list. The latter isn't fully implemented yet; see the
new FIXME.
llvm-svn: 123210
|
| |
|
|
| |
llvm-svn: 123184
|
| |
|
|
|
|
|
|
|
|
|
|
| |
template whose last parameter is a parameter pack. This allows us to
form a call to, e.g.,
template<typename ...Args1, typename ...Args2>
void f(std::pair<Args1, Args2> ...pairs);
given zero or more instances of "pair".
llvm-svn: 122973
|
| |
|
|
|
|
|
|
| |
parameter packs, along with ParmVarDecl::isParameterPack(), which
looks for function parameter packs. Use these routines to fix some
obvious FIXMEs.
llvm-svn: 122904
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
expansions with something that is easier to use correctly: a new
template argment kind, rather than a bit on an existing kind. Update
all of the switch statements that deal with template arguments, fixing
a few latent bugs in the process. I"m happy with this representation,
now.
And, oh look! Template instantiation and deduction work for template
template argument pack expansions.
llvm-svn: 122896
|
| |
|
|
|
|
| |
Previously designated anonymous fields were found via name lookup. This redesign uses the fact that an IndirectFieldDecl declaration will always follow an anonymous implicit field to remove the special case of name lookup.
llvm-svn: 122387
|
| |
|
|
|
|
|
| |
information caused token-annotation to fail in funny ways. Fixes
<rdar://problem/8595386>.
llvm-svn: 122338
|
| |
|
|
|
|
|
| |
don't provide their own explicit visibility attributes should get them
from the template. Fixes rdar://problem/8778497.
llvm-svn: 122136
|
| |
|
|
|
|
|
|
|
|
|
| |
visibility. Fixes PR8713.
I've disabled a test which was testing that you can #pragma pop visibility
to get out of a namespace's visibility attribute. We should probably just
diagnose that as an error unless it's instrumental to someone's system
headers.
llvm-svn: 121459
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
"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
|
| |
|
|
|
|
| |
unsigned integer" warnings.
llvm-svn: 121143
|
| |
|
|
|
|
| |
introduced in r121023.
llvm-svn: 121025
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
reason this is limited to C++, and it's certainly not limited to temporaries.
llvm-svn: 120996
|
| |
|
|
| |
llvm-svn: 120897
|
| |
|
|
| |
llvm-svn: 120828
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
- Negative ChainingSize doesn't make sense, make it unsigned.
llvm-svn: 119943
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 118293
|
| |
|
|
|
|
| |
check that the TargetNestedNameDecl is the same first.
llvm-svn: 118239
|
| |
|
|
| |
llvm-svn: 118034
|
| |
|
|
|
|
|
| |
with their own explicit visibility attributes. Basically we only want to
apply a single visibility attribute from any particular ancestry.
llvm-svn: 117998
|
| |
|
|
|
|
|
|
| |
isInlined() just gives meaningless results for non-definitions.
Fixes rdar://problem/8614470
llvm-svn: 117887
|
| |
|
|
|
|
|
|
|
|
| |
independently of whether they're definitions, then teach IR generation to
ignore non-explicit visibility when emitting declarations. Use this to
make sure that RTTI, vtables, and VTTs get the right visibility.
More of rdar://problem/8613093
llvm-svn: 117781
|
| |
|
|
|
|
|
|
| |
whether it's a declaration or not, then ignores that information for
declarations unless it was explicitly given. It's not totally clear
how that should be mapped into a sane system, but make an effort.
llvm-svn: 117780
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for namespace-scope variable declarations.
Apply visibility in IR gen to variables that are merely declared
and never defined. We were previously emitting these with default
visibility unless they were declared with private_extern.
Ignore global visibility settings when computing visibility for
a declaration's context, and key several conditions on whether a
visibility attribute exists anywhere in the hierarchy as opposed
to whether it exists at the current level.
llvm-svn: 117729
|