r193815 - Clang modules: collect exports recursively

[Richard Smith]

On Fri, Nov 1, 2013 at 6:47 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:

> On Thu, Oct 31, 2013 at 6:47 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> > I had a go at writing a test for this (attached). However... my test
> fails
> > both with and without your change.
>
> Indeed.  Seems like it fails because:
> - recursive_visibility_a.inner is not imported (only
> recursive_visibility_a is),
> - thus the 'inner' submodule is not showing up in any of the import lists,
> - and because of this getExportedModules() is not returning the
> correct module set -- it only considers modules that are imported.
>
> Should it also add the immediate exported submodules to the list,
> along with re-exported modules?  I'm not sure about the best way to
> implement this.
>
> Also, I think using ADL in templates is a very indirect way of testing
> this (although, I should admit, a real-life way of testing).


Name visibility in template instantiations is the only thing that
isModuleVisible is used for at the moment, and ADL seemed like a reasonable
way of triggering that lookup.


>  I
> thought it would be useful to have a tool that dumps the visibility
> sets for modules imported in a given TU (possibly explaining why a
> certain module is visible).  This would not only simplify debugging,
> but would allow us to test this easily.


That'd be a significant investment in infrastructure for something whose
observable effects we can already test, but if you want to go that way, I
won't complain =) I'd like to have the lit test regardless, though, to test
the observable behavior.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131101/9f8e21d9/attachment.html>