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.