| 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
|
| |
|
|
|
|
|
|
|
|
|
| |
declared, rather than putting them into the template parameter scope. We
previously had *no record* in the scope for class template declarations, once
those declarations completed and their template parameter scopes were popped.
This in turn caused us to be unable to merge class template declarations that
were declared in the global scope (where we use scope lookup rather than
DeclContext lookup for merging), when loading a module.
llvm-svn: 216311
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
anyway. If -ast-dump *is* also provided, then dump the AST declarations as well
as the lookup results. This is invaluable for cross-correlating the lookup
information with the declarations actually found.
llvm-svn: 215393
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
whether the definition of the template is visible rather than checking whether
the instantiated definition happens to be in an imported module.
llvm-svn: 208150
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
While investigating some debug info issues, Eric and I came across a
particular template case where the location of a decl was quite
different from the range of the same decl. It might've been rather
helpful if the dumper had actually showed us this.
llvm-svn: 205396
|
| |
|
|
|
|
|
|
|
| |
an out-of-date external decls list). This happens if we declare some names,
force the lookup table for the decl context to be built, import a module that
adds more decls for the name, then write out our module without looking up the
name.
llvm-svn: 204694
|
| |
|
|
|
|
|
| |
the update set rather than the current DeclContext. Add test for the local
extern case too.
llvm-svn: 204568
|
| |
|
|
|
|
|
| |
out a visible update record for that namespace even if it was never declared in
this module.
llvm-svn: 204554
|
| |
|
|
| |
llvm-svn: 204116
|
| |
|
|
|
|
|
| |
template specialization (from different modules), dump them all, so that every
declaration is dumped somewhere.
llvm-svn: 204100
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
name lookup from lazily deserializing the other declarations with the same
name, by tracking a bit to indicate whether a name in a DeclContext might have
additional external results. This also allows lazier reconciling of the lookup
table if a module import adds decls to a pre-existing DC.
However, this exposes a pre-existing bug, which causes a regression in
test/Modules/decldef.mm: if we have a reference to a declaration, and a
later-imported module adds a redeclaration, nothing causes us to load that
redeclaration when we use or emit the reference (which can manifest as a
reference to an undefined inline function, a use of an incomplete type, and so
on). decldef.mm has been extended with an additional testcase which fails with
or without this change.
llvm-svn: 190293
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
This is at least good documentation, but also opens the possibility of
using pipefail.
llvm-svn: 185652
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constructing a lookup table.
Previously, buildLookup would add lookup table entries for each item lexically
within the DC, and adding the first entry with a given name would trigger the
external source to add all its entries with that name. Then buildLookup would
carry on and re-add those entries all over again.
Instead, follow a simple rule: a declaration from an external source is only
ever made visible by the external source. One exception to this: since we don't
usually build a lookup table for the TU in C, and we never serialize one, we
don't expect the external source to provide lookups in the TU in C, so we build
those ones ourselves.
llvm-svn: 184696
|
|
|
llvm-svn: 184689
|
