C++ Logo

sg15

Advanced search

Re: [isocpp-core] Named modules, macros, and re-exporting header units

From: Gabriel Dos Reis <gdr_at_[hidden]>
Date: Fri, 16 Dec 2022 18:20:59 +0000
[Dani]

  * We need to take into account [module.import]/5<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule%23import-note-4&data=05%7C01%7Cgdr%40microsoft.com%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950831466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=byeh2EKEieKDzA0jZYMXRJl6dwK5orkXvGvvRVMAyBA%3D&reserved=0> that states that imports *not* nominating header units do *not* affect the preprocessor state.

Yes, but the source of confusion is that the specification of importing a named module is as if you take the exported module-import-declarations in the nominated modules and then execute those in the importing translation units, and those don't get subject to the fundamental constraint that you quote.


  * Current implementations disagree: https://twitter.com/DanielaKEngert/status/1603421930337484803<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FDanielaKEngert%2Fstatus%2F1603421930337484803&data=05%7C01%7Cgdr%40microsoft.com%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950831466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vtmqk7fgDZUby9mvmwgpe920vDFmnJM%2FK%2FWbdvnMhok%3D&reserved=0>

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.

-- Gaby

From: Daniela Engert <dani_at_[hidden]>
Sent: Friday, December 16, 2022 10:07 AM
To: core_at_[hidden]
Cc: Gabriel Dos Reis <gdr_at_[hidden]>; sg15_at_[hidden]
Subject: Re: [isocpp-core] Named modules, macros, and re-exporting header units

Am 16.12.2022 um 18:58 schrieb Gabriel Dos Reis via Core:
Hi,

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%237&data=05%7C01%7Cgdr%40microsoft.com%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950674784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WhUifSXwf1Y16BFLHhBqERKzX9hjy%2Fi1v2S1DiJZENc%3D&reserved=0>

When 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%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950674784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qUdtMsK5eAYeUyiw88iM0SIHEmOGnNAjnlHmi2Eu7W8%3D&reserved=0> imports a translation unit T, it also imports all translation units imported by exported 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%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950674784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qUdtMsK5eAYeUyiw88iM0SIHEmOGnNAjnlHmi2Eu7W8%3D&reserved=0>s in T; such translation units are said to be exported<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%23def%3Amodule%2Cexported&data=05%7C01%7Cgdr%40microsoft.com%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950674784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CH0cF%2FwzZ5DflEuzSU8pZnr3A6C%2BYR4sn8b7MJS7Ozg%3D&reserved=0> by T.<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%237.sentence-1&data=05%7C01%7Cgdr%40microsoft.com%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950674784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2t8iUyu4SCEXSPScxTmEy8wiwVQ%2Bw2M6kk9h%2FbBap6c%3D&reserved=0> Additionally, when 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%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950831466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2hrJBP4mklw5ozp6ERQFU8Z05uL2NCIq20G1DfPXSf8%3D&reserved=0> 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://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%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950831466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2hrJBP4mklw5ozp6ERQFU8Z05uL2NCIq20G1DfPXSf8%3D&reserved=0>s in the module unit purview of U.<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%237.sentence-2&data=05%7C01%7Cgdr%40microsoft.com%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950831466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mT92hN5ImPA9ZVqHjYxGaope3S%2Fz7xtSCf4%2BY2IeUtA%3D&reserved=0>91<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%23footnote-91&data=05%7C01%7Cgdr%40microsoft.com%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950831466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Z2JQS4CcasmmOfRxwqnYWONT0RxEOPUIYFbc7LrMFrs%3D&reserved=0> These rules can in turn lead to the importation of yet more translation units.<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%237.sentence-3&data=05%7C01%7Cgdr%40microsoft.com%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950831466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lWb7ns8ErDHZhJlfmJC21cqmXEbRVBFEoJgofDgwIy4%3D&reserved=0>

places no restrictions on "it also imports all translation units imported by exported 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%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950831466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2hrJBP4mklw5ozp6ERQFU8Z05uL2NCIq20G1DfPXSf8%3D&reserved=0>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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcplusplus%2FCWG%2Fissues%2F199&data=05%7C01%7Cgdr%40microsoft.com%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950831466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TBdVycGIZVRQDl%2BqHLnnxdPgNpZ96hEd7pXRb2QjLVE%3D&reserved=0>

to add an example that importing named modules don't bring in any macros at all. That is a fundamental invariant for anything to work. In addition to adding the example, I believe we need to clarify the wording. The fact that the text is confusing on this aspect is a defect, from my perspective.

We need to take into account [module.import]/5<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule%23import-note-4&data=05%7C01%7Cgdr%40microsoft.com%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950831466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=byeh2EKEieKDzA0jZYMXRJl6dwK5orkXvGvvRVMAyBA%3D&reserved=0> that states that imports *not* nominating header units do *not* affect the preprocessor state. Current implementations disagree: https://twitter.com/DanielaKEngert/status/1603421930337484803<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FDanielaKEngert%2Fstatus%2F1603421930337484803&data=05%7C01%7Cgdr%40microsoft.com%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950831466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vtmqk7fgDZUby9mvmwgpe920vDFmnJM%2FK%2FWbdvnMhok%3D&reserved=0>

Thanks,

Dani

Thanks,

-- Gaby



_______________________________________________

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%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950831466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OdDT3arNR4xxfRNZzEFQ3v60SWRlHxTrEPYk93r%2Bhdc%3D&reserved=0>

Link to this post: http://lists.isocpp.org/core/2022/12/13656.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fcore%2F2022%2F12%2F13656.php&data=05%7C01%7Cgdr%40microsoft.com%7Cb65141afad404e23d77608dadf904377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068107950831466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aN4z9LWKqmbTyxdWfdYLZmHuVqmsihLuNWBrLPazX10%3D&reserved=0>


--
PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

Received on 2022-12-16 18:21:03