[Boris]
> One potential complication of recreating the macro isolation semantics
> directly is that you will also isolate include guards which means that
> common headers might have to be scanned multiple times for the same
> TU (the same situation would occur in your current approach if you
> are building the "macro-only BMIs" from scratch for each TU).

I am still unable to grok why this is a problem, since an include guard is necessarily "exported" by a header unit. Please, help me understand why this is a problem or a complication. Walk me, slowly, through the steps. (*)

> Gaby suggested to me (in a private email) that this can be avoided
> but (according to my understanding, at least) it will require a
> pretty sophisticated macro dependency analysis (I can elaborate
> if there is interest).

Attached is a short note I wrote back in 2016-2017 that I circulated internally within Microsoft for the attention of "early adopters" and other engineers interested in adopting Modules (a TS at the time of the writing). Interestingly, it is just as relevant today as it was 5 years ago. I shared it with Boris a week or so ago; I suspect that is relevant to the conversation.

Comments, suggestions, defects most welcome so I (and the community) can learn.

PS: Yes, I need to turn this into executable code so people can play with it.
[*] As I age, I am no longer able to claim I am as good as I was yesterday when I wrote the code at 3am a couple of days ago.

-- Gaby


-----Original Message-----
From: Boris Kolpackov <boris_at_[hidden]>
Sent: Tuesday, May 17, 2022 4:09 AM
To: Michael Spencer <bigcheesegs_at_[hidden]>
Cc: Evolution Working Group mailing list <ext_at_[hidden]>; Gabriel Dos Reis <gdr_at_[hidden]>; Tooling Study Group (SG15) <sg15_at_[hidden]>
Subject: Re: [isocpp-ext] Can we expect that all C++ source files can have the same suffix?

Michael Spencer <bigcheesegs_at_[hidden]> writes:

> Yes, we perfectly model the preprocessor state as it pertains to
> dependencies. Currently this is done by actually building a header unit
> that is empty except for the exported macros and then importing that,

Interesting, thanks for the information. Do you build such "macro-only
BMIs" once and then share them across all the TUs being scanned or do
you have to build them from scratch per-TU (thus potentially redoing
the same thing multiple times)?

Also, does the build system has any input (e.g., compiler options)
into how such BMIs are built? Feels like it would be natural for
the scanner to ask the build system to build these BMIs... (you
can probably see where I am going with this ;-)).


> [...] but it's possible to do this directly.

One potential complication of recreating the macro isolation semantics
directly is that you will also isolate include guards which means that
common headers might have to be scanned multiple times for the same
TU (the same situation would occur in your current approach if you
are building the "macro-only BMIs" from scratch for each TU). Here
is an example:

// importer.cpp
//
#include <functional>
import "header-unit1.hpp"; // Also includes <functional>.
import "header-unit2.hpp"; // Also includes <functional>.

In this example a naive implementation would end up scanning
<functional> multiple times.

Gaby suggested to me (in a private email) that this can be avoided
but (according to my understanding, at least) it will require a
pretty sophisticated macro dependency analysis (I can elaborate
if there is interest).


> The only issue is if you want to automatically detect `importable header`s
> by seeing `import <header>;`.

To me this looks like a recipe for build non-determinism. Even if you
ignore the case where parts are built independently, I believe to get
decent performance a build system will need to scan in parallel. Which
means the decision to consider a header importable will be racy.