| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
into multiple merged classes' TypeForDecl slots.
llvm-svn: 220331
|
|
|
|
|
|
|
| |
declaration in the instantiation if the previous declaration came from another
definition of the class template that got merged into the pattern definition.
llvm-svn: 219552
|
|
|
|
|
|
| |
until after we've had a chance to merge that tag.
llvm-svn: 219539
|
|
|
|
|
|
|
| |
merged context, pull in the lexical decls in that context, since one of them
may complete the redecl chain.
llvm-svn: 216652
|
|
|
|
|
|
| |
contexts, so that we can merge them when we merge the surrounding context.
llvm-svn: 216639
|
|
|
|
|
|
|
| |
pattern of an alias template declaration. Use this to merge alias templates
properly when they're members of class template specializations.
llvm-svn: 216437
|
|
|
|
|
|
|
| |
declaration has its definition instantiated in two sibling modules and they use
a partial specialization.
llvm-svn: 215616
|
|
|
|
|
|
|
|
|
|
| |
definitions (because some other declaration declares a special member that
isn't present in the canonical definition), we need to search *all* of them; we
can't just stop when we find the requested name in any of the definitions,
because that can fail to find things (and in particular, it can fail to find
the member of the canonical declaration and return a bogus ODR failure).
llvm-svn: 215612
|
|
|
|
|
|
|
| |
never present in Clang trunk, but was present in some of my development work,
and it seems like a useful test to have.
llvm-svn: 214154
|
|
|
|
| |
llvm-svn: 214152
|
|
|
|
|
|
| |
definition in order to apply isa<...>.
llvm-svn: 214151
|
|
|
|
| |
llvm-svn: 214124
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
gets explicitly specialized, don't reuse the previous class template
specialization declaration as a new declaration. The benefit here is fairly
marginal, it harms source fidelity, and this is horrible to model if the
specialization was imported from another module (without this change, it
asserts or worse).
llvm-svn: 209552
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
out a visible update record for that namespace even if it was never declared in
this module.
llvm-svn: 204554
|
|
|
|
|
|
| |
merged declarations of a class template.
llvm-svn: 192746
|
|
|
|
|
|
| |
(eg through template instantiations in multiple modules).
llvm-svn: 192740
|
|
|
|
| |
llvm-svn: 192560
|
|
|
|
|
|
|
|
|
|
|
|
| |
it is an implicit instantiation of a class template specialization), pick the
first-loaded definition to be the canonical definition, and merge all other
definitions into it.
This is still rather incomplete -- we need to extend every form of declaration
that can appear within a CXXRecordDecl to be redeclarable if it came from an
AST file (this includes fields, enumerators, ...).
llvm-svn: 190315
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in one module but is only declared as a friend in another module, keep it
visible in the result of the merge.
This is incomplete on two axes:
1) Our handling of local extern declarations is basically broken (we put them
in the wrong decl context, and don't find them in redeclaration lookup, unless
they've previously been declared), and this results in them making friends
visible after a merge.
2) Eventually we'll need to mark that this has happened, and more carefully
check whether a declaration should be visible if it was only visible in some
of the modules in which it was declared. Fortunately it's rare for the
identifier namespace of a declaration to change along its redeclaration chain.
llvm-svn: 187639
|
|
|
|
|
|
| |
module.
llvm-svn: 187556
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sufficient to only consider names visible at the point of instantiation,
because that may not include names that were visible when the template was
defined. More generally, if the instantiation backtrace goes through a module
M, then every declaration visible within M should be available to the
instantiation. Any of those declarations might be part of the interface that M
intended to export to a template that it instantiates.
The fix here has two parts:
1) If we find a non-visible declaration during name lookup during template
instantiation, check whether the declaration was visible from the defining
module of all entities on the active template instantiation stack. The defining
module is not the owning module in all cases: we look at the module in which a
template was defined, not the module in which it was first instantiated.
2) Perform pending instantiations at the end of a module, not at the end of the
translation unit. This is general goodness, since it significantly cuts down
the amount of redundant work that is performed in every TU importing a module,
and also implicitly adds the module containing the point of instantiation to
the set of modules checked for declarations in a lookup within a template
instantiation.
There's a known issue here with template instantiations performed while
building a module, if additional imports are added later on. I'll fix that
in a subsequent commit.
llvm-svn: 187167
|
|
|
|
|
|
|
|
|
|
| |
numbers as we deserialize class template partial specializations. We can't
assume that the old sequence numbers will work.
The sequence numbers are still deterministic, but are now a lot less
predictable for class template partial specializations in modules/PCH.
llvm-svn: 184811
|
|
|
|
| |
llvm-svn: 184791
|
|
llvm-svn: 184689
|