https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122908
--- Comment #10 from Nathaniel Shead <nshead at gcc dot gnu.org> --- (In reply to Bernardo Negri from comment #9) > (In reply to Nathaniel Shead from comment #6) > > What makes you say that? Within a module interface unit, only in a private > > module fragment is an exposure allowed, by > > https://eel.is/c++draft/basic.link#17. > Confusion about the difference between the private module fragment and the > global module fragment. Thank you for clarifying, I was not reading the spec > correctly. > > However, this just makes me more confused about the intended use for global > module fragments, since it is possible to violate exposure rules by merely > #include ing a header. > > Consider a 3rd party library: > // class.h > template <typename T> > static size_t getSize(const std::vector<T> &list) { > return list.size(); > } > template <typename T> > class Class { > void processList(std::vector<T> list) { > getSize(list); > } > } > > This library is fine to use with the traditional .cpp plus header files > structure (though it is deprecated), but if you try to use it in a project > with modules, just #include ing it on the GMF is an error according to the > standard. The only solution I know is with header units, which are not well > supported by build systems. Are there any other ways? Unfortunately not, the header would need to be fixed. For what it's worth, if the header was included in more than one TU this was always IFNDR (ill-formed, no diagnostic required) due to the ODR violation; modules has just made this mandated IF (ill-formed) in more cases. GCC 16 does add a flag to allow accepting some usages of TU-local GM entities without it being considered an exposure, to assist in migration (especially for C libraries that may be difficult or impossible to update), but there are a number of caveats. See https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wexpose-global-module-tu-local. > One example of where this kind of stuff is used constantly is in Qt code, > which means trying to do anything Qt-related with modules will lead to a ton > of errors unless you treat every Qt class as TU-local to avoid marking them > as decl-reachable. And even then you'll get errors just from instantiating a > template. Yes, if that is the case ideally Qt would be able to adjust any such issues in their headers to allow them to work more seamlessly with modules. That may of course take some time unfortunately. > You are right, the program I attached is technically incorrect according to > the standard, because Class::testFn (not TU-local) names internalLink > (TU-local). Everything else is necessary for GCC to consider Class > decl-reachable. > > (In reply to Nathaniel Shead from comment #8) > > Thanks for your time and your bug report, it's greatly appreciated. Let me > > know if there's anything else I can try and clarify. > > It is I who should be thanking you for explaining to a newbie these complex > C++ concepts. All your feedback is also appreciated.
