https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118799
--- Comment #3 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:2eb3d7454ee578335b7719aadfb9e37a8456f1f1
commit r15-8013-g2eb3d7454ee578335b7719aadfb9e37a8456f1f1
Author: Nathaniel Shead
Date: Sun Feb 9 00:37:48 2025 +1100
c++/modules: Better handle no-linkage decls in unnamed namespaces
[PR118799]
There are two issues with no-linkage decls (e.g. explicit type aliases)
in unnamed namespaces that this patch fixes.
Firstly, we don't currently handle exporting no-linkage decls in unnamed
namespaces. This should be ill-formed in [module.export], since having
an exported declaration within a namespace-definition makes the
namespace definition exported (p2), but an unnamed namespace has
internal linkage thus violating p3.
Secondly, by the standard it appears to be possible to emit unnamed
namespaces from named modules in certain scenarios, for instance when
they contain a type alias (which is not itself an entity). This patch
makes the adjustments needed to ensure we don't error in this scenario.
PR c++/118799
gcc/cp/ChangeLog:
* module.cc (depset::hash::is_tu_local_entity): Only types,
functions, variables, and template (specialisations) can be
TU-local. Explicit type aliases are TU-local iff the type they
refer to are.
(module_state::write_namespaces): Allow unnamed namespaces in
named modules.
(check_module_decl_linkage): Error for all exported declarations
in an unnamed namespace.
gcc/testsuite/ChangeLog:
* g++.dg/modules/export-6.C: Adjust error message, add check for
no-linkage decls in namespace.
* g++.dg/modules/internal-4_b.C: Allow exposing a namespace with
internal linkage. Type aliases are not entities and so never
exposures.
* g++.dg/modules/using-30_a.C: New test.
* g++.dg/modules/using-30_b.C: New test.
* g++.dg/modules/using-30_c.C: New test.
Signed-off-by: Nathaniel Shead
Reviewed-by: Jason Merrill
