Commit Graph

59 Commits

Author SHA1 Message Date
Richard Smith 4abe0a8d82 C++ modules: fix a bug where loading a declaration with some name would prevent
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
2013-09-09 07:34:56 +00:00
Richard Smith 7ecc31b032 When merging redeclaration chains across modules, if a declaration is visible
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
2013-08-02 01:09:12 +00:00
Richard Smith b71782b7e5 Fix assert when instantiating a default argument of a template defined in a
module.

llvm-svn: 187556
2013-08-01 04:12:04 +00:00
Richard Smith 0e5d7b8c6b When we perform dependent name lookup during template instantiation, it's not
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
2013-07-25 23:08:39 +00:00
Rafael Espindola 925213b0fa Add 'not' to commands that are expected to fail.
This is at least good documentation, but also opens the possibility of
using pipefail.

llvm-svn: 185652
2013-07-04 16:16:58 +00:00
Richard Smith 5de91b58d0 Fix deserializing of class template partial specializations. Assign sequence
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
2013-06-25 01:25:15 +00:00
Richard Smith bf78e646e1 Check for matching template-parameter-lists when merging template declarations.
llvm-svn: 184791
2013-06-24 22:51:00 +00:00
Richard Smith cf4ab520b5 Avoid adding entries to the DeclContext lookup table multiple times when lazily
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
2013-06-24 07:20:36 +00:00
Richard Smith 8f8f05cf00 Slightly improve cross-module merging for function templates.
llvm-svn: 184689
2013-06-24 04:45:28 +00:00