From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by sourceware.org (Postfix) with ESMTPS id C74073858C2C for ; Fri, 22 Apr 2022 15:06:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C74073858C2C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=sandoe.co.uk Received: (qmail 83622 invoked from network); 22 Apr 2022 15:06:53 -0000 X-APM-Out-ID: 16506400138361 X-APM-Authkey: 257869/1(257869/1) 3 Received: from unknown (HELO ?192.168.1.214?) (81.138.1.83) by smtp002.apm-internet.net with SMTP; 22 Apr 2022 15:06:53 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: [modules] Preprocessing requires compiled header unit modules From: Iain Sandoe In-Reply-To: Date: Fri, 22 Apr 2022 16:06:52 +0100 Cc: Ben Boeckel , gcc@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Boris Kolpackov X-Mailer: Apple Mail (2.3445.104.21) X-Spam-Status: No, score=-8.7 required=5.0 tests=BAYES_00, KAM_COUK, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_SHORT, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2022 15:06:56 -0000 > On 22 Apr 2022, at 15:08, Boris Kolpackov = wrote: >=20 > Ben Boeckel writes: >=20 >> On Thu, Apr 21, 2022 at 06:05:52 +0200, Boris Kolpackov wrote: >>=20 >>> I don't think it is. A header unit (unlike a named module) may = export >>> macros which could affect further dependencies. Consider: >>>=20 >>> import "header-unit.hpp"; // May or may not export macro FOO. >>>=20 >>> #ifdef FOO >>> import "header-unit2.hpp"; >>> #endif >>=20 >> I agree that the header needs to be *found*, but scanning cannot = require >> a pre-existing BMI for that header. >=20 > Well, if scanning cannot require a pre-existing BMI but a pre-existing > BMI is required to get accurate dependency information, then something > has to give. >=20 > You hint at a potential solution in your subsequent email: >=20 >> Can't it just read the header as if it wasn't imported? AFAIU, that's >> what GCC did in Jan 2019. I understand that CPP state is probably not >> easy, but something to consider. >=20 > The problem with this approach is that a header import and a header > include have subtly different semantics around macros. In particular, > the header import does not "see" macros defined by the importer while > the header include does. Here is an example: >=20 > // file: header-unit.hpp > // > #ifdef BAR > #define FOO > #endif >=20 > // file: importer.cpp > // > #define BAR > import "header-unit.hpp"; // Should not "see" BAR. > //#include "header-unit.hpp" // Should "see" BAR. >=20 > #ifdef FOO > import "header-unit2.hpp"; > #endif >=20 > In this example, if you treat import of header-unit.hpp as > include, you will get incorrect dependency information. >=20 > So to make this work correctly we will need to re-create the > macro isolation semantics of import for include. >=20 > Even if we manage to do this, there are some implications I > am not sure we will like: the isolated macros will contain > inclusion guards, which means we will keep re-scanning the > same files potentially many many time. Here is an example, > assume each header-unitN.hpp includes or imports : >=20 > // file: importer.cpp > // > import ; // Defined _GLIBCXX_FUNCTIONAL include >=20 > import "header-unit1.hpp"; // Ignores _GLIBCXX_FUNCTIONAL > import "header-unit2.hpp"; // Ditto. > import "header-unit3.hpp"; // Ditto. > import "header-unit4.hpp"; // Ditto. The standard has the concept of an =E2=80=9Cimportable header=E2=80=9D = which is implementation-defined. We could choose that only headers that are self-contained (i.e. = unaffected by external defines) are =E2=80=9Cimportable=E2=80=9D (thus the remaining headers = would not be eligible for include- translation). That would mean that we could rely on processing any = import by processing the header it is created from? Perhaps that is too great a restriction = and we need to be more clever=E2=80=A6. @ben, in relation to an earlier question: https://eel.is/c++draft/cpp.import#note-4 says that predefined macro names are not introduced by #define and that = the implementation is encouraged not to treat them as if they were IIUC, that means that -D/U (and preamble ones) are not emitted into the = macro stream - however it might well be the case that they *are* part of the module identifing = hash (and preserved as part of the captured command line). Iain=