Am 18.01.2024 um 08:00 schrieb Chuanqi Xu via SG15:
>
> Yeah, I just made a simple draft:
> https://isocpp.org/files/papers/D3092R0.html to include things related
> to ABI and modules in my mind immediately.
> It may be easy to miss some important points. So I retitled this
> thread and mark it as RFC. Please chime in freely if you find there
> isimprecise description or anything missed.
>
A few clarifications from my side:

3) every module TU of a named module has *exactly one* module
declaration (no plural). Those, and all following declarations until the
end of the TU are *part* of the module purview. This means, a module TU
contains (a part of) the named module, and optionally a part of the
global module. A module TU compiles into a BMI, an object file, or both.

4.1) Translation units *explicitly or implicitly* importing modules
*must* call the initializer functions of the imported modules *within
the sequence* of the dynamic-initializers in the TU. Initializations of
entities at namespace scope are *appearance-ordered*. This (recursively)
*extends* into imported modules at the point of appearance of the import
declaration.

4.2) module linkage applies to *all non-TU-local* entities in the
purview which don't get external linkage by other means like export or
language linkage specifications. 'Inline' doesn't change attachment and
therefore doesn't affect linkage in this respect.

5.1) "that what if internal linkage entites get imported?". You can't
import them because they can't be exported in the first place.

Thanks
   Dani


> Thanks,
> Chuanqi
>
> ------------------------------------------------------------------
> From:Michael Spencer <bigcheesegs_at_[hidden]>
> Send Time:2024 Jan. 18 (Thu.) 07:48
> To:SG15<sg15_at_[hidden]>
> Cc:Evolution Working Group mailing list<ext_at_[hidden]>;
> Chuanqi<chuanqi.xcq_at_[hidden]>
> Subject:Re: [SG15] Could we summarize precise ABI expectation for
> modules?
>
> On Wed, Jan 10, 2024 at 9:14 PM Chuanqi Xu via SG15
> <sg15_at_[hidden]> wrote:
> Hi Experts,
>
> There is a discussion about ABI in modules in
> https://github.com/itanium-cxx-abi/cxx-abi/issues/170.
>
> John Said:
>
> > Okay. The committee needs to understand that that's not how this
> works, alright? Whenever the language adds new constructs,
> compilers have to figure out how to compile them, and that needs
> to go into this specification. Modules add quite a few new
> constructs, and they have non-trivial implications for compilers
> because they create new kinds of information flow between
> translation units. The traditional understanding of ABI boundaries
> in C++ has always been that any information in the translation
> unit is fair game for the compiler to use. A perhaps-naive
> understanding of how importing a module interface unit works is
> that the exported declarations from that module are now available
> in the importing translation unit essentially as if they were
> declared there (just preserving the knowledge that they in fact
> came from a different module). So if the idea is now that some of
> the information in a module interface unit is not supposed to be
> used by its importers, that's an important shift. That's true even
> if you've identified a reasonable formalism that seems to unify
> previous behavior with the new intended interpretation, because
> compilers need to make sure they're implementing the intent of
> that formalism.
>
> Then I feel it is worth to bring the topic here. Should we try
> to summarize a precise ABI expectation for modules? And if yes,
> how should we get involved in? And although it is not required to
> be formal, I feel a paper might be a good outcome.
>
> BTW, previously I sent a discussion about ABI in modules to
> SG15 (https://lists.isocpp.org/sg15/2023/11/2064.php) as I think
> it is implementation details. But given what John said, I feel it
> may be worthy to bring this to EWG too.
>
> Thanks,
> Chuanqi
>
> I think it would be good to cover what expectations people
> actually have. Most of the committee's discussion has been around
> what implementation strategies are allowed, not really any
> guarantees the language is trying to make (as the language
> standard can't actually do that).
>
> I think it would be best to phrase this as what source changes
> potentially impact ABI, and thus require recompiling all dependencies.
>
> - Michael Spencer
>
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15

-- 
PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5