On 2/9/25 6:38 AM, Nathaniel Shead wrote:
On Sun, Feb 09, 2025 at 01:16:00AM +1100, Nathaniel Shead wrote:
Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap + regtest
passes?
-- >8 --
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. This patch makes
the adjustments needed to ensure we don't error in this case.
One thing to note with this is that it means that the following sample:
export module M;
namespace {
struct Internal {};
using Alias = Internal;
}
will still error:
test.cpp:4:9: error: ‘using {anonymous}::Alias = struct {anonymous}::Internal’
exposes TU-local entity ‘struct {anonymous}::Internal’
4 | using Alias = Internal;
| ^~~~~
test.cpp:3:10: note: ‘struct {anonymous}::Internal’ declared with internal
linkage
3 | struct Internal {};
| ^~~~~~~~
https://eel.is/c++draft/basic.link#17 is the relevant paragraph here,
but I'm not 100% sure what it says about this example; I suppose that
given Alias isn't really an entity maybe this should be OK?
Right; a non-template alias isn't an entity, and p17 only makes exposure
ill-formed if the declaration declares an entity.
But either way we definitely don't want to emit this alias.
Maybe the correct approach here is to mark an explicit type alias
TU-local iff the type it refers to is itself TU-local? So something
like this on top of this patch:
Hmm, since it isn't an entity, it also isn't a TU-local entity. Maybe
in finalize_dependencies, ignore is_exposure if the dep is not an entity?
Jason
