https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121574
--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Nathaniel Shead <[email protected]>: https://gcc.gnu.org/g:99c2ed7407154164c25b4f12e82af77c67cde3a3 commit r16-5048-g99c2ed7407154164c25b4f12e82af77c67cde3a3 Author: Nathaniel Shead <[email protected]> Date: Thu Oct 30 23:13:21 2025 +1100 c++/modules: Allow ignoring some TU-local exposure errors in GMF [PR121574] A frequent issue with migrating to C++20 modules has been dealing with third-party libraries with internal functions or data. This causes GCC to currently refuse to build the module if any references to these internal-linkage declarations escape into the module CMI. This can seem needlessly hostile, however, especially since we have the capabilities to support this (to a degree) from header units, albeit with the inherent ODR issues associated with their use. In aid of this, this patch demotes the error to a pedwarn in various scenarios, by treating some declarations as not being TU-local even if they otherwise would have been. Effort has been made to not alter semantics of valid programs, and to continue to diagnose cases that the standard says we must. In particular, any code in the module purview is still a hard error, due to the inherent issues with exposing TU-local entities, and the lack of any migration requirements. Because this patch is just to assist migration, we only deal with the simplest (yet most common) cases: namespace scope functions and variables. Types are hard to handle neatly as we risk getting thousands of unhelpful warnings as we continue to walk the type body and find new TU-local entities to complain about. Templates are also tricky because it's hard to tell if an instantiation that occurred in the module purview only refers to global module entities or if it's inadvertantly exposing a purview entity as well. Neither of these are likely to occur frequently in third-party code; if need be, this can be relaxed later as well. Similarly, even in the GMF a constexpr variable with a TU-local value will not be usable in constant expressions in the importer, and since we cannot easily warn about this from the importer we continue to make this an error in the module interface. PR c++/121574 gcc/c-family/ChangeLog: * c.opt: New warning '-Wexpose-global-module-tu-local'. * c.opt.urls: Regenerate. gcc/ChangeLog: * doc/invoke.texi: Document '-Wexpose-global-module-tu-local'. gcc/cp/ChangeLog: * module.cc (depset::disc_bits): Replace 'DB_REFS_TU_LOCAL_BIT' and 'DB_EXPOSURE_BIT' with new four flags 'DB_{REF,EXPOSE}_{GLOBAL,PURVIEW}_BIT'. (depset::is_tu_local): Support checking either for only purview TU-local entities or any entity described TU-local by standard. (depset::refs_tu_local): Likewise. (depset::is_exposure): Likewise. (depset::hash::make_dependency): A constant initialized to a TU-local variable is always considered a purview exposure. (is_exposure_of_member_type): Adjust sanity checks to handle if we ever relax requirements for TU-local types. (depset::hash::add_dependency): Differentiate referencing purview or GMF TU-local entities. (depset::hash::diagnose_bad_internal_ref): New function. (depset::hash::diagnose_template_names_tu_local): New function. (depset::hash::finalize_dependencies): Handle new warnings that might be needed for GMF TU-local entities. gcc/testsuite/ChangeLog: * g++.dg/modules/internal-17_a.C: New test. * g++.dg/modules/internal-17_b.C: New test. Signed-off-by: Nathaniel Shead <[email protected]> Reviewed-by: Jason Merrill <[email protected]>
