On Thu, Jan 04, 2024 at 05:42:34PM -0500, Jason Merrill wrote: > On 1/4/24 17:24, Nathaniel Shead wrote: > > On Thu, Jan 04, 2024 at 03:31:50PM -0500, Jason Merrill wrote: > > > On 1/2/24 17:40, Nathaniel Shead wrote: > > > > Static data members marked 'inline' should be emitted in TUs where they > > > > are ODR-used. We need to make sure that statics imported from modules > > > > are correctly added to the 'pending_statics' map so that they get > > > > emitted if needed, otherwise the attached testcase fails to link. > > > > > > Hmm, this seems wrong to me; I'd think that static data members marked > > > inline should be emitted in the module, and not in importers. > > > > That's what I'd initially thought too, but this is at least consistent > > with non-class inlines (variables and functions), which similarly only > > get emitted in TUs that they're ODR-used rather than always (and only) > > being emitted within the module. > > > > I guess an alternative would be to change it around so that all > > exported definitions are marked as needed in the module interface file > > (and emitted there), and then setting some flag so that they're never > > emitted in importers. > > Yes, that would be my expectation. What do other modules implementations > do?
Clang only emits ODR-used declarations (same as GCC currently). MSVC emits all inline variables (whether exported or not) but no inline functions. > > I'm not entirely sure what flag that would be > > though, I still haven't quite wrapped my head what controls what with > > regards to this, and I'm not convinced it wouldn't break template > > instantiations. > > I would guess avoid emitting if DECL_MODULE_IMPORT_P && > DECL_MODULE_ATTACH_P. Ah yup, that would make sense. I guess, thinking about it more, we should then also ensure that all TREE_PUBLIC declarations are emitted in the module interface even if not exported, since they may be needed in implementation units? > > I wonder if this might also be related to the issue Nathan noted with > > regards to block-scope class methods, which I haven't completely worked > > out how to solve yet otherwise (see > > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638223.html). > > Indeed. > > Jason > I'll give implementing this a try then, if you think that would be sensible. (Where by "this" I mean "emit all public declarations in module interface files, whether used or not".)
