From: Boris Kolpackov <boris@codesynthesis.com>
To: Ben Boeckel <ben.boeckel@kitware.com>
Cc: gcc@gcc.gnu.org
Subject: Re: [modules] Preprocessing requires compiled header unit modules
Date: Fri, 22 Apr 2022 16:08:00 +0200 [thread overview]
Message-ID: <boris.20220422145332@codesynthesis.com> (raw)
In-Reply-To: <YmFIjb/GwaEX9GVQ@farprobe>
Ben Boeckel <ben.boeckel@kitware.com> writes:
> On Thu, Apr 21, 2022 at 06:05:52 +0200, Boris Kolpackov wrote:
>
> > I don't think it is. A header unit (unlike a named module) may export
> > macros which could affect further dependencies. Consider:
> >
> > import "header-unit.hpp"; // May or may not export macro FOO.
> >
> > #ifdef FOO
> > import "header-unit2.hpp";
> > #endif
>
> I agree that the header needs to be *found*, but scanning cannot require
> a pre-existing BMI for that header.
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.
You hint at a potential solution in your subsequent email:
> 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.
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:
// file: header-unit.hpp
//
#ifdef BAR
#define FOO
#endif
// file: importer.cpp
//
#define BAR
import "header-unit.hpp"; // Should not "see" BAR.
//#include "header-unit.hpp" // Should "see" BAR.
#ifdef FOO
import "header-unit2.hpp";
#endif
In this example, if you treat import of header-unit.hpp as
include, you will get incorrect dependency information.
So to make this work correctly we will need to re-create the
macro isolation semantics of import for include.
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 <functional>:
// file: importer.cpp
//
import <functional>; // Defined _GLIBCXX_FUNCTIONAL include
import "header-unit1.hpp"; // Ignores _GLIBCXX_FUNCTIONAL
import "header-unit2.hpp"; // Ditto.
import "header-unit3.hpp"; // Ditto.
import "header-unit4.hpp"; // Ditto.
next prev parent reply other threads:[~2022-04-22 14:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 23:46 Ben Boeckel
2022-04-21 4:05 ` Boris Kolpackov
2022-04-21 12:05 ` Ben Boeckel
2022-04-21 17:59 ` Iain Sandoe
2022-04-21 18:08 ` Ben Boeckel
2022-04-21 18:18 ` Iain Sandoe
2022-04-22 14:08 ` Boris Kolpackov [this message]
2022-04-22 15:06 ` Iain Sandoe
2022-04-25 9:20 ` Boris Kolpackov
2022-04-22 16:05 ` Ben Boeckel
2022-04-25 9:42 ` Boris Kolpackov
2022-04-25 11:34 ` Ben Boeckel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=boris.20220422145332@codesynthesis.com \
--to=boris@codesynthesis.com \
--cc=ben.boeckel@kitware.com \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).