| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
on top of a local declaration of the same entity, we still need to remember
that we loaded the first one or we may fail to merge the second one properly.
llvm-svn: 226765
|
|
|
|
|
|
|
| |
load the definition data from the declaration itself. In that case, merge
properly; don't assume the prior definition is the same as our own.
llvm-svn: 226761
|
|
|
|
|
|
| |
pair<iterator, bool> as per the C++ standard's associative container concept.
llvm-svn: 222335
|
|
|
|
|
|
|
| |
is a re-commit of Doug's r154844 (modernized and updated to fit into current
Clang).
llvm-svn: 221918
|
|
|
|
|
|
|
|
|
| |
For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>);
In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>);
Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info.
Differential Revision: http://reviews.llvm.org/D4002
llvm-svn: 221663
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implicit module builds are not well-suited to a lot of build systems. In
particular, they fare badly in distributed build systems, and they lead to
build artifacts that are not tracked as part of the usual dependency management
process. This change allows explicitly-built module files (which are already
supported through the -emit-module flag) to be explicitly loaded into a build,
allowing build systems to opt to manage module builds and dependencies
themselves.
This is only the first step in supporting such configurations, and it should
be considered experimental and subject to change or removal for now.
llvm-svn: 220359
|
|
|
|
| |
llvm-svn: 219657
|
|
|
|
|
|
| |
until after we've had a chance to merge that tag.
llvm-svn: 219539
|
|
|
|
|
|
|
|
| |
initializers, and captured VLA types so that we can
answer questions like "is this a bit-field" without
looking at the enclosing DeclContext. NFC.
llvm-svn: 219522
|
|
|
|
|
|
|
| |
merging of namespace aliases across modules and improves source fidelity.
Incidentally also fixes PR20816.
llvm-svn: 217103
|
|
|
|
|
|
| |
typedef name for linkage purposes. When loading the type, delay loading its typedef until we've finished loading and merging the type. In its place, save out the name of the typedef, which we need for merging purposes.
llvm-svn: 216806
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4368
llvm-svn: 216649
|
|
|
|
|
|
| |
contexts, so that we can merge them when we merge the surrounding context.
llvm-svn: 216639
|
|
|
|
|
|
|
|
| |
on CXXRecordDecls when merging definitions, and make it pass by not trying to
save and restore this flag across AST serialization/deserialization. For
CXXRecordDecls, we have a separate mechanism to manage this.
llvm-svn: 216633
|
|
|
|
|
|
|
| |
functions. Also don't needlessly pull in non-canonical declarations of the
overridden virtual functions.
llvm-svn: 216503
|
|
|
|
|
|
|
| |
pattern of an alias template declaration. Use this to merge alias templates
properly when they're members of class template specializations.
llvm-svn: 216437
|
|
|
|
| |
llvm-svn: 216417
|
|
|
|
|
|
|
|
|
|
| |
declarations. We can't expect to find them in the canonical definition
of the class, because that's not where they live.
This means we no longer reject real ODR violations with friend declarations,
but we weren't consistently doing so anyway.
llvm-svn: 216369
|
|
|
|
|
|
|
| |
purposes, look for other typedefs with that same name and merge into their
named tag declaration if there is one.
llvm-svn: 216312
|
|
|
|
|
|
|
|
|
| |
Predefined decls like 'Protocol' in objc are not loaded from AST files,
so we cannot rely on loading the canonical decl to complete the redecl
chain for redeclarations of these decls. The broken redecl chain was
non-circular, so looping over redecls() would hang.
llvm-svn: 215929
|
|
|
|
|
|
| |
needing to mention the size.
llvm-svn: 215869
|
|
|
|
|
|
|
| |
members from all redefinitions of a class that have them, in case the special
member is defined in one module but only declared in another.
llvm-svn: 215675
|
|
|
|
|
|
|
| |
declaration has its definition instantiated in two sibling modules and they use
a partial specialization.
llvm-svn: 215616
|
|
|
|
|
|
|
|
|
|
| |
redefinitions of that namespace have already been loaded. When writing out the
names in a namespace, if we see a name that is locally declared and had
imported declarations merged on top of it, export the local declaration as the
lookup result, because it will be the most recent declaration of that entity in
the redeclaration chain of an importer of the module.
llvm-svn: 215518
|
|
|
|
|
|
| |
Instead, perform them carefully immediately.
llvm-svn: 215147
|
|
|
|
|
|
|
|
|
| |
also emit the updated 'operator delete' looked up for that destructor. Switch
from UpdateDecl to an actual update record when this happens due to implicitly
defining a special member function and unify this code path and the one for
instantiating a function definition.
llvm-svn: 215132
|
|
|
|
|
|
|
|
|
|
|
| |
they're somehow missing a body. Looks like this was left behind when the loop
was generalized, and it's not been problematic before because without modules,
a used, implicit special member function declaration must be a definition.
This was resulting in us trying to emit a constructor declaration rather than
a definition, and producing a constructor missing its member initializers.
llvm-svn: 214473
|
|
|
|
| |
llvm-svn: 214459
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of a function has a resolved exception specification, then all declarations of
the function do.
We should probably improve the AST representation to make this implicit (perhaps
only store the exception specification on the canonical declaration), but this
fixes things for now.
The testcase for this (which used to assert) also exposes the actual bug I was
trying to reduce here: we sometimes fail to emit the body of an imported
special member function definition. Fix for that to follow.
llvm-svn: 214458
|
|
|
|
|
|
|
|
| |
FunctionProtoType::ExtProtoInfo. Most of the users of these fields don't care
about the other ExtProtoInfo bits and just want to talk about the exception
specification.
llvm-svn: 214450
|
|
|
|
| |
llvm-svn: 214124
|
|
|
|
|
|
|
|
|
| |
redeclaration chains when pulling in a declaration. We need the redecl chain
unless we know some other declaration will trigger it to be pulled in; that
happens if our originally-canonical declaration had all the knowledge that
we have (and isn't us).
llvm-svn: 213043
|
|
|
|
|
|
| |
pattern.
llvm-svn: 212836
|
|
|
|
|
|
|
|
|
| |
into their container; we won't find them there. These things are already being
merged when they're added to their primary template's folding set, so this
merging is redundant (and causes us to reject-valid because we think we've
found an odr violation).
llvm-svn: 212788
|
|
|
|
|
|
|
| |
the key functions table. Don't hold references to anything within that table
across such an access.
llvm-svn: 212437
|
|
|
|
| |
llvm-svn: 211764
|
|
|
|
|
|
|
| |
record, mark all subsequent decls as 'used' too, to maintain the AST invariant
that getPreviousDecl()->Used implies this->Used.
llvm-svn: 211050
|
|
|
|
|
|
|
| |
member functions), ensure that the redecl chain never transitions from 'inline'
to 'not inline', since that violates an AST invariant.
llvm-svn: 209794
|
|
|
|
|
|
| |
rather than saving and restoring it.
llvm-svn: 209557
|
|
|
|
|
|
| |
CXXRecordDecls when modules is enabled.
llvm-svn: 209482
|
|
|
|
|
|
|
|
|
| |
instantiated in another module, and the instantiation uses a partial
specialization, include the partial specialization and its template arguments
in the update record. We'll need them if someone imports the second module and
tries to instantiate a member of the template.
llvm-svn: 209472
|
|
|
|
| |
llvm-svn: 209392
|
|
|
|
|
|
|
|
| |
declaration of that entity in from one of those modules, keep track of the fact
that we've not completed the redeclaration chain yet so that we can pull the
remaining declarations in from the other module if they're needed.
llvm-svn: 209161
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ensure that querying the first declaration for its most recent declaration
checks for redeclarations from the imported module.
This works as follows:
* The 'most recent' pointer on a canonical declaration grows a pointer to the
external AST source and a generation number (space- and time-optimized for
the case where there is no external source).
* Each time the 'most recent' pointer is queried, if it has an external source,
we check whether it's up to date, and update it if not.
* The ancillary data stored on the canonical declaration is allocated lazily
to avoid filling it in for declarations that end up being non-canonical.
We'll still perform a redundant (ASTContext) allocation if someone asks for
the most recent declaration from a decl before setPreviousDecl is called,
but such cases are probably all bugs, and are now easy to find.
Some finessing is still in order here -- in particular, we use a very general
mechanism for handling the DefinitionData pointer on CXXRecordData, and a more
targeted approach would be more compact.
Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was
addressing only a corner of the full problem space here. That's not covered
by this patch.
Early performance benchmarks show that this makes no measurable difference to
Clang performance without modules enabled (and fixes a major correctness issue
with modules enabled). I'll revert if a full performance comparison shows any
problems.
llvm-svn: 209046
|
|
|
|
|
|
| |
declarations, and duplicating code between them.
llvm-svn: 208662
|
|
|
|
|
|
|
| |
Required pulling LambdaExpr::Capture into its own header.
No functionality change.
llvm-svn: 208470
|
|
|
|
| |
llvm-svn: 208077
|
|
|
|
|
|
|
| |
This fixes a bug where an update record causes us to load an entity that refers
to an entity we've not finished loading yet, resulting in badness.
llvm-svn: 207603
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
together. This is extremely hairy, because in general we need to have loaded
both the template and the pattern before we can determine whether either should
be merged, so we temporarily violate the rule that all merging happens before
reading a decl ends, but *only* in the case where a template's pattern is being
loaded while loading the template itself.
In order to accomodate this for class templates, delay loading the injected
class name type for the pattern of the template until after we've loaded the
template itself, if we happen to load the template first.
llvm-svn: 207063
|
|
|
|
|
|
| |
imported from another module, emit an update record, rather than using the broken decl rewriting mechanism. If multiple modules do this, merge the definitions together, much as we would if they were separate declarations.
llvm-svn: 206680
|