[Bug c++/105397] C++ modules vs -fvisibility option

2022-12-21 Thread iains at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105397

--- Comment #3 from Iain Sandoe  ---
the import places attributes at the end.

so 
import module Foo [[]];

it would seem to be symmetrical to have:

export import Foo [[...]];
export module Foo [[...]];

but, ts present, (if I read it correctly) it seems that the WD says

export [[...]] module Foo;
export [[...]] int bar ();

which would then be weird with export [[...]] import Foo [[...]];

[Bug c++/105397] C++ modules vs -fvisibility option

2022-12-08 Thread bugzilla.gcc at me dot benboeckel.net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105397

--- Comment #2 from Ben Boeckel  ---
> Perhaps the best option is to default the visibility of the implicit 
> functions to the widest visibility of any function or object in module 
> purview exposed by the TU.

What to do about `extern "C"` APIs made available by a module? Is that even
allowed? Imagine a library providing some C API by implementing in C++ modules;
should the module initializer be public API too?