]> git.ipfire.org Git - thirdparty/gcc.git/commit
c++/modules: Allow ignoring some TU-local exposure errors in GMF [PR121574]
authorNathaniel Shead <nathanieloshead@gmail.com>
Thu, 30 Oct 2025 12:13:21 +0000 (23:13 +1100)
committerNathaniel Shead <nathanieloshead@gmail.com>
Wed, 5 Nov 2025 23:19:17 +0000 (10:19 +1100)
commit99c2ed7407154164c25b4f12e82af77c67cde3a3
tree04acad964d73c6d6fde8b0b735d943f7e0a8a777
parent35e029530f256bb6302a3cae650d7eaef5514a36
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 <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
gcc/c-family/c.opt
gcc/c-family/c.opt.urls
gcc/cp/module.cc
gcc/doc/invoke.texi
gcc/testsuite/g++.dg/modules/internal-17_a.C [new file with mode: 0644]
gcc/testsuite/g++.dg/modules/internal-17_b.C [new file with mode: 0644]