Gabriel Dos Reis <gdr_at_[hidden]> writes:

> [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. (*)

The key point here is not that the guard is exported but that the
guard defined by the importer should not be visible inside the
header unit. Here is an annotated version of my original example:

// importer.cpp
//
#include <functional> // Defines, say, _GLIBCXX_FUNCTIONAL as an
                           // include guard.

import "header-unit1.hpp"; // Also includes <functional>.
                           //
                           // But does not "see" any macros defined by
                           // the importer, including _GLIBCXX_FUNCTIONAL.
                           
import "header-unit2.hpp"; // Also includes <functional>.
                           //
                           // Ditto.


> Attached is a short note I wrote back in 2016-2017 [...]. I shared
> it with Boris a week or so ago; I suspect that is relevant to the
> conversation.

Ok, let's see if I understood that paper by applying it to this
specific example: the idea is that we fully scan #include <functional>
found in importer.cpp and while doing that we calculate the set of
macros that (1) are defined (or not defined) before this directive and
that (2) affect the contents of <functional>. We do it by analyzing
every #if-expression that we encounter while processing <functional>.

Then, when we encounter the second #include <functional> but this time
inside header-unit1.hpp, we cannot just skip it due to include guards
(since they have been isolated per the above). But we can check if the
set of macros we have calculated for it before has exactly the same
values as the first time, and if that's the case, then we can skip
processing <functional> by simply re-using the set of macros that were
(newly) defined after processing <functional> the first time (which we
would also need to stash).

Sounds about right or am I missing something?