This is an archive of the discontinued LLVM Phabricator instance.

Fix name lookup within modules during template instantiation
ClosedPublic

Authored by rsmith on Jul 23 2013, 5:05 PM.

Details

Summary

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.

With this change, a simple "Hello world" program now compiles with a modularized libc++ (with only one top-level module, for now -- cross-top-level-module merging of template specializations doesn't work yet).

Diff Detail

Event Timeline

rsmith updated this revision to Unknown Object (????).Jul 24 2013, 3:34 PM

Cache computation of defining module for a template for the duration of its instantiation.

rsmith updated this revision to Unknown Object (????).Jul 24 2013, 3:37 PM

This looks *great*. It's simpler than I was expecting.

One concern about the caching, though: we might be forced to perform instantiation before we've seen all of the imports (say, due to a constexpr function template definition getting instantiated), which means the cache could be incomplete. I suggest invalidating based on the ASTReader's current generation.

rsmith accepted this revision.May 30 2014, 12:52 PM
rsmith added a reviewer: rsmith.

Names visible in the current translation unit are always considered to be visible, so I don't think it's possible to observe the change in visible modules for the currently-being-built module. (We also never query it, since it's not an owning module for any declaration.)

This revision is now accepted and ready to land.May 30 2014, 12:52 PM
rsmith closed this revision.May 30 2014, 12:52 PM

This was committed way back in r187167. I added a FIXME for the out-of-date cache issue in r209915.