Commit Graph

57 Commits

Author SHA1 Message Date
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