Date: Wed, 21 Dec 2022 20:10:01 +0000
[Jens]
> "The pp-tokens comprising a /module-import-declaration/ that nominates
> a /header-name/ are also recognized by the preprocessor as a pp-import
> directive, and result in macros defined at the end of phase 4 of
> translation of the header unit being made visible as described
> in [cpp.import]."
The problem here is that there is no pp-tokens comprising a /module-import-declaration/.
A /module-import-declaration/ is introduced by an /import-keyword/, which is not required to be pp-token (it could be __import or __import_kwd in some implementations, when we think about preprocessed files).
What the preprocessor recognizes is the /pp-import/ preprocessor production.
I wonder if the note 4 should just go.
-- Gaby
-----Original Message-----
From: Core <core-bounces_at_[hidden]> On Behalf Of Jens Maurer via Core
Sent: Wednesday, December 21, 2022 12:02 PM
To: core_at_[hidden]; sg15_at_[hidden]
Cc: Jens Maurer <jens.maurer_at_[hidden]>
Subject: Re: [isocpp-core] [SG15] Named modules, macros, and re-exporting header units
On 21/12/2022 19.47, Gabriel Dos Reis via Core wrote:
> [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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1Q4K%2FHwqvN0wlKvZYlaZsVF0XHoSZKP58e2JllOR3Eo%3D&reserved=0> itself is actively inviting that kind of confusion. For example, the note 4 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%23note-4&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FziGZJxoEHoxALHr7hQuwVDK0100YsBkCJk9J7CtHW0%3D&reserved=0> says
>
>
>
> [/Note 4 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%23note-4&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FziGZJxoEHoxALHr7hQuwVDK0100YsBkCJk9J7CtHW0%3D&reserved=0>/: A /module-import-declaration/ <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%23nt%3Amodule-import-declaration&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6bhHYFi7sH8ZeAstTnWPqJZ6sbHHp9zR6pnvOs9B3vg%3D&reserved=0> nominating a /header-name/ <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Flex.header%23nt%3Aheader-name&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=67HNkYxkeuZFeM3gLhXgElO42bTEODggZ8gBlH5LZB8%3D&reserved=0> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fcpp.import&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zNbagmoAItx%2BRoKafBX7h2M9rayeDGPg%2FsHx5svHcyc%3D&reserved=0>. <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%235.sentence-6&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CxOW4dcJ7W5LtJd4RTpsjQQPKv0232kyZNDHldVSie8%3D&reserved=0> Any other /module-import-declaration/ <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%23nt%3Amodule-import-declaration&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6bhHYFi7sH8ZeAstTnWPqJZ6sbHHp9zR6pnvOs9B3vg%3D&reserved=0> does not make macros visible. <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%235.sentence-7&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=A6TUjdvuDVyccRerz8kRiy%2Fu1Sw1OtyOZuta3TqDtjU%3D&reserved=0> - /end note/]
>
>
>
> How can a /module-import-declaration/ be recognized by the preprocessor? Which production makes that possible?
Would something like
"The pp-tokens comprising a /module-import-declaration/ that nominates
a /header-name/ are also recognized by the preprocessor as a pp-import
directive, and result in macros defined at the end of phase 4 of
translation of the header unit being made visible as described
in [cpp.import]."
be better, in your view?
Jens
_______________________________________________
Core mailing list
Core_at_[hidden]
Subscription: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fcore&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=geUgU%2BP4APXIWp%2B0ysELdWfFsth90z4aTatBwERMnCg%3D&reserved=0
Link to this post: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fcore%2F2022%2F12%2F13680.php&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CogFRgCluqq3eelzTxJvi5Po5HagkHw5oM3rD95xiTc%3D&reserved=0
> "The pp-tokens comprising a /module-import-declaration/ that nominates
> a /header-name/ are also recognized by the preprocessor as a pp-import
> directive, and result in macros defined at the end of phase 4 of
> translation of the header unit being made visible as described
> in [cpp.import]."
The problem here is that there is no pp-tokens comprising a /module-import-declaration/.
A /module-import-declaration/ is introduced by an /import-keyword/, which is not required to be pp-token (it could be __import or __import_kwd in some implementations, when we think about preprocessed files).
What the preprocessor recognizes is the /pp-import/ preprocessor production.
I wonder if the note 4 should just go.
-- Gaby
-----Original Message-----
From: Core <core-bounces_at_[hidden]> On Behalf Of Jens Maurer via Core
Sent: Wednesday, December 21, 2022 12:02 PM
To: core_at_[hidden]; sg15_at_[hidden]
Cc: Jens Maurer <jens.maurer_at_[hidden]>
Subject: Re: [isocpp-core] [SG15] Named modules, macros, and re-exporting header units
On 21/12/2022 19.47, Gabriel Dos Reis via Core wrote:
> [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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1Q4K%2FHwqvN0wlKvZYlaZsVF0XHoSZKP58e2JllOR3Eo%3D&reserved=0> itself is actively inviting that kind of confusion. For example, the note 4 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%23note-4&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FziGZJxoEHoxALHr7hQuwVDK0100YsBkCJk9J7CtHW0%3D&reserved=0> says
>
>
>
> [/Note 4 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%23note-4&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FziGZJxoEHoxALHr7hQuwVDK0100YsBkCJk9J7CtHW0%3D&reserved=0>/: A /module-import-declaration/ <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%23nt%3Amodule-import-declaration&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6bhHYFi7sH8ZeAstTnWPqJZ6sbHHp9zR6pnvOs9B3vg%3D&reserved=0> nominating a /header-name/ <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Flex.header%23nt%3Aheader-name&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=67HNkYxkeuZFeM3gLhXgElO42bTEODggZ8gBlH5LZB8%3D&reserved=0> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fcpp.import&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zNbagmoAItx%2BRoKafBX7h2M9rayeDGPg%2FsHx5svHcyc%3D&reserved=0>. <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%235.sentence-6&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CxOW4dcJ7W5LtJd4RTpsjQQPKv0232kyZNDHldVSie8%3D&reserved=0> Any other /module-import-declaration/ <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%23nt%3Amodule-import-declaration&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6bhHYFi7sH8ZeAstTnWPqJZ6sbHHp9zR6pnvOs9B3vg%3D&reserved=0> does not make macros visible. <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%235.sentence-7&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=A6TUjdvuDVyccRerz8kRiy%2Fu1Sw1OtyOZuta3TqDtjU%3D&reserved=0> - /end note/]
>
>
>
> How can a /module-import-declaration/ be recognized by the preprocessor? Which production makes that possible?
Would something like
"The pp-tokens comprising a /module-import-declaration/ that nominates
a /header-name/ are also recognized by the preprocessor as a pp-import
directive, and result in macros defined at the end of phase 4 of
translation of the header unit being made visible as described
in [cpp.import]."
be better, in your view?
Jens
_______________________________________________
Core mailing list
Core_at_[hidden]
Subscription: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fcore&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=geUgU%2BP4APXIWp%2B0ysELdWfFsth90z4aTatBwERMnCg%3D&reserved=0
Link to this post: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fcore%2F2022%2F12%2F13680.php&data=05%7C01%7Cgdr%40microsoft.com%7Ccb2381acfedc45e9dd4408dae38e48bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638072497497347483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CogFRgCluqq3eelzTxJvi5Po5HagkHw5oM3rD95xiTc%3D&reserved=0
Received on 2022-12-21 20:10:04