Date: Sat, 17 Dec 2022 08:30:46 +0100
Am 17.12.2022 um 00:10 schrieb Jens Maurer via Core:
>
> On 16/12/2022 18.58, Gabriel Dos Reis via Core wrote:
>> In the SG15 telecon this morning, the issue of whether a named modules can bring in macros via re-exported header units was discussed.
>>
>> The issue is that the current specification of module-import-declaration: 10.3/7<https://eel.is/c++draft/module.import#7>
>>
>>
>>
>> When a /module-import-declaration/<https://eel.is/c++draft/module.import#nt:module-import-declaration> imports a translation unit T, it also imports all translation units imported by exported /module-import-declaration/<https://eel.is/c++draft/module.import#nt:module-import-declaration>/s/ in T; such translation units are said to be /exported/<https://eel.is/c++draft/module.import#def:module,exported> by T.<https://eel.is/c++draft/module.import#7.sentence-1> Additionally, when a /module-import-declaration/<https://eel.is/c++draft/module.import#nt:module-import-declaration> in a module unit of some module M imports another module unit U of M, it also imports all translation units imported by non-exported /module-import-declaration/<https://eel.is/c++draft/module.import#nt:module-import-declaration>/s/ in the module unit purview of U.<https://eel.is/c++draft/module.import#7.sentence-2>91<https://eel.is/c++draft/module.import#footnote-91> These rules can in turn lead to
>> the importation of yet more translation units.<https://eel.is/c++draft/module.import#7.sentence-3>
> This clearly refers to "translation units", and translation units are a phase 7 concept
> per [lex.phases] p7:
>
> "Whitespace characters separating tokens are no longer significant. Each preprocessing token is converted
> into a token (5.6). The resulting tokens are syntactically and semantically analyzed and translated as a
> translation unit."
>
> At that point, macros simply don't exist anymore.
>
> I support adding examples and notes, but I feel there is nothing normatively amiss.
>
>> places no restrictions on “it also imports all translation units imported by exported /module-import-declaration/<https://eel.is/c++draft/module.import#nt:module-import-declaration>/s/ in T;”.
>>
>> It was pointed out that there is a CWG issue
>>
>>
>>
>> [cpp.import] Example should demonstrate that module imports do not import macros · Issue #199 · cplusplus/CWG · GitHub<https://github.com/cplusplus/CWG/issues/199>
> This is not a CWG issue; it's a request that a CWG issue be created,
> once the chair feels like it.
>
> I felt like it:
>
> https://cplusplus.github.io/CWG/issues/2667.html
>
> Please have a look whether you like my suggested resolution.
Thanks Jens for this swift action. I like it.
Dani
>
> Jens
> _______________________________________________
> Core mailing list
> Core_at_[hidden]
> Subscription:https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post:http://lists.isocpp.org/core/2022/12/13665.php
>
> On 16/12/2022 18.58, Gabriel Dos Reis via Core wrote:
>> In the SG15 telecon this morning, the issue of whether a named modules can bring in macros via re-exported header units was discussed.
>>
>> The issue is that the current specification of module-import-declaration: 10.3/7<https://eel.is/c++draft/module.import#7>
>>
>>
>>
>> When a /module-import-declaration/<https://eel.is/c++draft/module.import#nt:module-import-declaration> imports a translation unit T, it also imports all translation units imported by exported /module-import-declaration/<https://eel.is/c++draft/module.import#nt:module-import-declaration>/s/ in T; such translation units are said to be /exported/<https://eel.is/c++draft/module.import#def:module,exported> by T.<https://eel.is/c++draft/module.import#7.sentence-1> Additionally, when a /module-import-declaration/<https://eel.is/c++draft/module.import#nt:module-import-declaration> in a module unit of some module M imports another module unit U of M, it also imports all translation units imported by non-exported /module-import-declaration/<https://eel.is/c++draft/module.import#nt:module-import-declaration>/s/ in the module unit purview of U.<https://eel.is/c++draft/module.import#7.sentence-2>91<https://eel.is/c++draft/module.import#footnote-91> These rules can in turn lead to
>> the importation of yet more translation units.<https://eel.is/c++draft/module.import#7.sentence-3>
> This clearly refers to "translation units", and translation units are a phase 7 concept
> per [lex.phases] p7:
>
> "Whitespace characters separating tokens are no longer significant. Each preprocessing token is converted
> into a token (5.6). The resulting tokens are syntactically and semantically analyzed and translated as a
> translation unit."
>
> At that point, macros simply don't exist anymore.
>
> I support adding examples and notes, but I feel there is nothing normatively amiss.
>
>> places no restrictions on “it also imports all translation units imported by exported /module-import-declaration/<https://eel.is/c++draft/module.import#nt:module-import-declaration>/s/ in T;”.
>>
>> It was pointed out that there is a CWG issue
>>
>>
>>
>> [cpp.import] Example should demonstrate that module imports do not import macros · Issue #199 · cplusplus/CWG · GitHub<https://github.com/cplusplus/CWG/issues/199>
> This is not a CWG issue; it's a request that a CWG issue be created,
> once the chair feels like it.
>
> I felt like it:
>
> https://cplusplus.github.io/CWG/issues/2667.html
>
> Please have a look whether you like my suggested resolution.
Thanks Jens for this swift action. I like it.
Dani
>
> Jens
> _______________________________________________
> Core mailing list
> Core_at_[hidden]
> Subscription:https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post:http://lists.isocpp.org/core/2022/12/13665.php
-- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
Received on 2022-12-17 07:30:52