r193815 - Clang modules: collect exports recursively
richard at metafoo.co.uk
Fri Nov 1 18:56:38 PDT 2013
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>
> > I had a go at writing a test for this (attached). However... my test
> > 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.
> 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...
More information about the cfe-commits