On Fri, 10 Jun 2022 at 01:35, Boris Kolpackov via SG15 <
sg15_at_[hidden]> wrote:

> Daniel Ruoso via SG15 <sg15_at_[hidden]> writes:
>
> > Let's suppose you have the header foo.h:
> >
> > ```
> > #ifndef INCLUDED_FOO_H
> > #define INCLUDED_FOO_H
> > #define SOMETHING 1
> > #endif
> > ```
> >
> > Now, let's suppose you have another header, let's say bar.h, with:
> >
> > ```
> > import <foo.h>
> > #ifdef SOMETHING
> > import <something.h>
> > #else
> > import <somethingelse.h>
> > #endif
> > ```
> >
> > Let's suppose both `foo.h` and `bar.h` are importable headers.
> >
> > In the dependency scanning phase, we're not expected to have a bmi for
> > all units yet, since we don't know the order in which we're meant to
> > process them.
> >
> > How is the dependency scanning supposed to work in that case?
>
> The current "state of the art" is to scan the headers themselves,
> as if they were #include'ed.
>
> But just treating them as real #include's won't be conforming,
> consider:
>
> ```
> #ifndef INCLUDED_FOO_H
> #define INCLUDED_FOO_H
> #ifdef FOO
> # define SOMETHING 1
> #endif
> #endif
> ```
>
> ```
> #define FOO
> import <foo.h>; // Should not "see" FOO.
> #include <foo.h> // Should "see" FOO.
> ```
>
> So the plan is to scan the headers themselves but recreating
> the importation semantics with regards to macro isolation.
>

FWIW, Clang supports this behavior. Essentially instead of having a single
per-compilation notion of preprocessor state, there's one preprocessor
state for the main input and one more for each header unit, and a header
unit import or an include-translated #include switches to that header
unit's state; leaving such a header switches back to the state of the
includer but makes the included header unit's macros visible in the
includer in the same way as an import of a pre-translated header does.
(Clang's parser and semantic analysis also supports this state switching,
triggered by the preprocessor injecting placeholder tokens on each module
transition, so you can parse header units in the same compilation as their
importers and get modular semantics from them.)

But this has potential scalability issues. The most recent
> thread on this top starts here:
>
> https://lists.isocpp.org/ext/2022/04/19015.php
>
> (It's also available in the public sg15 archives except for
> the first email: https://lists.isocpp.org/sg15/2022/05/1531.php).
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>