Em sex., 10 de jun. de 2022 às 04:35, Boris Kolpackov
<boris_at_[hidden]> escreveu:
> The current "state of the art" is to scan the headers themselves,
> as if they were #include'ed.
[...]
> So the plan is to scan the headers themselves but recreating
> the importation semantics with regards to macro isolation.

This brings us to another point that has been discussed a few times
(including an sg15 telecon last year), which is whether or not we
expect header units to be translated only once, or for it to be
dependent on the preprocessor arguments of the translation unit
importing them.

I, personally, am in the camp that header units should be translated
only once in the project, regardless of the preprocessor arguments
used in the translation unit importing it (and this was the consensus
we had in the sg15 meeting at the time).

It seems the consequence is that the compiler needs to be given not
only the list of header units and which files they point to for the
dependency scanning pass, but it also needs the instructions on how to
preprocess those header units.

I also agree that this seems to be the only reasonable way to implement this.

> But this has potential scalability issues. The most recent
> thread on this top starts here:

I don't know if I would call it a scalability issue, because it's not
significantly more expensive than the source inclusion. The compiler
just needs to create a new preprocessor state before starting to
preprocess the imported header. There's no requirement that a full bmi
be produced at that time, it just needs to know the resulting macros
after phase 4.

daniel