On 6/10/22 9:33 AM, Daniel Ruoso via SG15 wrote:
> 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).

I think it is ok, and possibly sometimes required, that a header unit be
translated more than once in a project. This places a burden on the
build system to ensure that the correct BMI is specified for every
importing TU, but if one wants to opt-in to that complexity I wish them
all the joy it may bring them. If such multiple importing TUs are
combined into a single program, then there is the requirement that the
distinct BMIs still conform with the ODR, but that is nothing new. I
don't think this is a situation that we need to optimize for; such
projects will be on their own for figuring out how scanning works in
this case. I'm guessing they would have to do multiple scans in some way.

Tom.

>
> 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
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15