diff options
| author | Nathaniel Shead <nathanieloshead@gmail.com> | 2025-10-30 23:13:21 +1100 |
|---|---|---|
| committer | Nathaniel Shead <nathanieloshead@gmail.com> | 2025-11-06 10:19:17 +1100 |
| commit | 99c2ed7407154164c25b4f12e82af77c67cde3a3 (patch) | |
| tree | 04acad964d73c6d6fde8b0b735d943f7e0a8a777 /libgrust/rustc-lib/stdarch/crates/std_detect | |
| parent | 35e029530f256bb6302a3cae650d7eaef5514a36 (diff) | |
| download | gcc-99c2ed7407154164c25b4f12e82af77c67cde3a3.zip gcc-99c2ed7407154164c25b4f12e82af77c67cde3a3.tar.gz gcc-99c2ed7407154164c25b4f12e82af77c67cde3a3.tar.bz2 | |
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>
Diffstat (limited to 'libgrust/rustc-lib/stdarch/crates/std_detect')
0 files changed, 0 insertions, 0 deletions
