On Fri, Jun 19, 2015 at 4:18 PM, Sean Silva <chisophu...@gmail.com> wrote:
> ================ > Comment at: include/clang/Basic/DiagnosticLexKinds.td:626 > @@ -625,1 +625,3 @@ > +def note_implicit_top_level_module_import_here : Note< > + "submodule of top-level module '%0' implicitly imported here">; > def warn_uncovered_module_header : Warning< > ---------------- > benlangmuir wrote: > > I'd just drop "submodule of top-level ". > I think it's an important qualification because the module that was in > fact imported is not %0. %0 is the top-level module containing it, and the > error is because some submodule of %0 (perhaps the one being imported, > perhaps not) has the missing file. > > From a user's perspective: "The header I included didn't ask for %0 to be > imported. It asked for this submodule of it". Ideally we would be able to > somehow communicate the "unity build" aspect of top-level modules for this > to make sense, but I couldn't find a way to fit all that in a diagnostic. > > Does that make sense? We use this kind of introductory text for a diagnostic produced within a module: In module '<top-level module>' imported from <use of submodule>: ... and a similar note for a diagnostic that occurs while implicitly building a module, so removing the "submodule of top-level" from your diagnostic would be consistent with that. In fact, I'm not sure your note is necessary; don't we already produce a "While building <top-level module> imported from <somewhere>" message prior to emitting the error message? http://reviews.llvm.org/D10423 > > EMAIL PREFERENCES > http://reviews.llvm.org/settings/panel/emailpreferences/ > > >
_______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits