On Thu, Jan 18, 2024 at 7:37 PM Chuanqi Xu via Ext <ext_at_[hidden]>
wrote:

> 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.
>
> ---
>
> > 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.
>
> Thanks,
> Chuanqi
>

When you are importing a module interface from a library you are linking
against you shouldn't make a .o file, as it will contain duplicate
definitions.

- Michael Spencer


>
> ------------------------------------------------------------------
> 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 is imprecise
> 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]> <bigcheesegs_at_[hidden]>
> Send Time:2024 Jan. 18 (Thu.) 07:48
> To:SG15<sg15_at_[hidden]> <sg15_at_[hidden]>
> Cc:Evolution Working Group mailing list<ext_at_[hidden]>
> <ext_at_[hidden]>; Chuanqi<chuanqi.xcq_at_[hidden]>
> <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 listSG15_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
>
> --
> PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
>
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2024/01/22483.php
>