Am 19.01.2024 um 04:37 schrieb Chuanqi Xu:
> Hi Dani and Ben,
>
> I should have addressed all your opinions in
> https://isocpp.org/files/papers/D3092R0.html except I commented
> additionally below. I tried to give a new number like `D3092R1` but it
> looks like the system doesn't allow us to update the revisions for `D`
> papers.
>
Thanks!


>
> > A module TU compiles into a BMI, an object file, or both.
>
> I didn't add this since I am confused. In my mind, all importable
> module unit should be compiled into a BMI and an object file. And the
> implementation module unit should be compiled into an object file.
> Then what is the case that a module unit should be compiled into a
> BMI? Also I feel my description is more clear so I didn't take this.

Module *implementation* units that are *not* module partitions are also
module TUs but can't export entities. Therefore they never create a BMI
but rather just an object file.

You're right, importable module TUs *must* create a BMI, no matter if
they happen to export entities or if they are "degenerate" and export
nothing. It is implementation-defined where the compiler emits e.g.
function bodies of non-exported functions into - either the BMI or the
object file. It's advisable to emit such function bodies into the object
file if they refer to TU-local entities to avoid exposures, but this is
not required. It's only the semantics and well-formedness that needs to
be maintained by the implementation.

Thanks,
    Dani

>
> Thanks,
> Chuanqi
>
> ------------------------------------------------------------------
> From: SG15 <sg15_at_[hidden]>
> Send Time:2024 Jan. 19 (Fri.) 00:12
> To:SG15<sg15_at_[hidden]>
> Cc:Daniela Engert<dani_at_[hidden]>; Evolution Working Group mailing
> list<ext_at_[hidden]>
> Subject:Re: [SG15] [RFC] [Modules] [ABI] Modules ABI requirement
>
> 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]://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
>
> --
> PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
>