On Fri, Nov 1, 2013 at 6:47 PM, Dmitri Gribenko <[email protected]> wrote:
> On Thu, Oct 31, 2013 at 6:47 PM, Richard Smith <[email protected]> > 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
