Date: Wed, 21 Dec 2022 18:47:47 +0000
[Richard]
* We already have explicit normative text that says the right thing, but given that an implementer has read it and misunderstood, it seems like it's not clear enough and that rules describing phase 7 of translation are being incorrectly applied in phase 4 as well.
It looks to me as if the text in section 10.3<https://eel.is/c++draft/module.import> itself is actively inviting that kind of confusion. For example, the note 4<https://eel.is/c++draft/module.import#note-4> says
[Note 4<https://eel.is/c++draft/module.import#note-4>: A module-import-declaration<https://eel.is/c++draft/module.import#nt:module-import-declaration> nominating a header-name<https://eel.is/c++draft/lex.header#nt:header-name> is also recognized by the preprocessor, and results in macros defined at the end of phase 4 of translation of the header unit being made visible as described in [cpp.import]<https://eel.is/c++draft/cpp.import>.<https://eel.is/c++draft/module.import#5.sentence-6> Any other module-import-declaration<https://eel.is/c++draft/module.import#nt:module-import-declaration> does not make macros visible.<https://eel.is/c++draft/module.import#5.sentence-7> - end note]
How can a module-import-declaration be recognized by the preprocessor? Which production makes that possible?
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Richard Smith via SG15
Sent: Friday, December 16, 2022 11:42 AM
To: C++ Core Language Working Group <core_at_[hidden]>
Cc: Richard Smith <richardsmith_at_[hidden]>; sg15_at_[hidden]
Subject: Re: [SG15] [isocpp-core] Named modules, macros, and re-exporting header units
On Fri, Dec 16, 2022, 10:23 Ville Voutilainen via Core <core_at_[hidden]<mailto:core_at_[hidden]>> wrote:
On Fri, 16 Dec 2022 at 20:21, Gabriel Dos Reis via SG15
<sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
> Exactly why we need to clarify the normative text to say explicitly that importing a named module does not bring in any macro even if the nominated module re-exported a header unit which might bring in macros if imported directly. Even if we believe there is a (long) chain of inference to arrive there, it is better to have an explicit normative text to that effect.
Agreed, having an import of a named module bring in a macro is
unhinged, and must be rectified via any means.
We already have explicit normative text that says the right thing, but given that an implementer has read it and misunderstood, it seems like it's not clear enough and that rules describing phase 7 of translation are being incorrectly applied in phase 4 as well. We should probably reiterate that the rules in the preprocessor section define the behaviour of phase 4 of translation and the rules elsewhere do not, and what that means for macro imports in particular. A couple of well-placed notes or examples seem well-suited for this purpose to me.
_______________________________________________
Core mailing list
Core_at_[hidden]<mailto:Core_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fcore&data=05%7C01%7Cgdr%40microsoft.com%7C3072c8a1188b4851831308dadf9d9b3b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068165260771572%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1kcZBkSbS9HS0ZOn3q57fwupay9%2BpKupXaam0chSuqA%3D&reserved=0>
Link to this post: http://lists.isocpp.org/core/2022/12/13659.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fcore%2F2022%2F12%2F13659.php&data=05%7C01%7Cgdr%40microsoft.com%7C3072c8a1188b4851831308dadf9d9b3b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068165260771572%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6nnQ7Jh5R%2BaTvs5a6GbDjnflZciQ8N%2Fhxa02Ws9qhgU%3D&reserved=0>
* We already have explicit normative text that says the right thing, but given that an implementer has read it and misunderstood, it seems like it's not clear enough and that rules describing phase 7 of translation are being incorrectly applied in phase 4 as well.
It looks to me as if the text in section 10.3<https://eel.is/c++draft/module.import> itself is actively inviting that kind of confusion. For example, the note 4<https://eel.is/c++draft/module.import#note-4> says
[Note 4<https://eel.is/c++draft/module.import#note-4>: A module-import-declaration<https://eel.is/c++draft/module.import#nt:module-import-declaration> nominating a header-name<https://eel.is/c++draft/lex.header#nt:header-name> is also recognized by the preprocessor, and results in macros defined at the end of phase 4 of translation of the header unit being made visible as described in [cpp.import]<https://eel.is/c++draft/cpp.import>.<https://eel.is/c++draft/module.import#5.sentence-6> Any other module-import-declaration<https://eel.is/c++draft/module.import#nt:module-import-declaration> does not make macros visible.<https://eel.is/c++draft/module.import#5.sentence-7> - end note]
How can a module-import-declaration be recognized by the preprocessor? Which production makes that possible?
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Richard Smith via SG15
Sent: Friday, December 16, 2022 11:42 AM
To: C++ Core Language Working Group <core_at_[hidden]>
Cc: Richard Smith <richardsmith_at_[hidden]>; sg15_at_[hidden]
Subject: Re: [SG15] [isocpp-core] Named modules, macros, and re-exporting header units
On Fri, Dec 16, 2022, 10:23 Ville Voutilainen via Core <core_at_[hidden]<mailto:core_at_[hidden]>> wrote:
On Fri, 16 Dec 2022 at 20:21, Gabriel Dos Reis via SG15
<sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
> Exactly why we need to clarify the normative text to say explicitly that importing a named module does not bring in any macro even if the nominated module re-exported a header unit which might bring in macros if imported directly. Even if we believe there is a (long) chain of inference to arrive there, it is better to have an explicit normative text to that effect.
Agreed, having an import of a named module bring in a macro is
unhinged, and must be rectified via any means.
We already have explicit normative text that says the right thing, but given that an implementer has read it and misunderstood, it seems like it's not clear enough and that rules describing phase 7 of translation are being incorrectly applied in phase 4 as well. We should probably reiterate that the rules in the preprocessor section define the behaviour of phase 4 of translation and the rules elsewhere do not, and what that means for macro imports in particular. A couple of well-placed notes or examples seem well-suited for this purpose to me.
_______________________________________________
Core mailing list
Core_at_[hidden]<mailto:Core_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fcore&data=05%7C01%7Cgdr%40microsoft.com%7C3072c8a1188b4851831308dadf9d9b3b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068165260771572%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1kcZBkSbS9HS0ZOn3q57fwupay9%2BpKupXaam0chSuqA%3D&reserved=0>
Link to this post: http://lists.isocpp.org/core/2022/12/13659.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fcore%2F2022%2F12%2F13659.php&data=05%7C01%7Cgdr%40microsoft.com%7C3072c8a1188b4851831308dadf9d9b3b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068165260771572%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6nnQ7Jh5R%2BaTvs5a6GbDjnflZciQ8N%2Fhxa02Ws9qhgU%3D&reserved=0>
Received on 2022-12-21 18:47:51