On Wed, Mar 6, 2019 at 4:01 PM Nathan Sidwell <nathan_at_[hidden]> wrote:

> On 3/6/19 3:01 PM, Mathias Stearn wrote:
> >
> >
> > On Wed, Mar 6, 2019 at 10:18 AM Nathan Sidwell <nathan_at_[hidden]
> > <mailto:nathan_at_[hidden]>> wrote:
> >
> > Yes, a BMI is required for a header import. Textually including the
> > header import's original header file is not equivalent.
> >
> >
> > It won't be required for the scan stage will it? If it is, there is a
> > bootstrapping problem because there is no good way to figure out which
> > order to build the header-unit BMIs in if they import other
> > header-units. I've been assuming that the scan stage will be able to
> > just temporarily mask off the defines and replace them with the correct
> > ones for the header-unit while scanning a file, so that scanning has no
> > generated dependencies.
>
> As header units export #defines, which can go on to determine the path
> of conditional inclusion, you have to decide:
>
> a) if you want precise scanning, you need the header units at scan time
>
> b) if you're ok with imprecise scanning (getting false positives). But
> you need something other than the C++ preprocessor
>

If in addition to being told which headers are importable, the
scanner/preprocessor is also told what flags are used for each of those
headers, how hard would it be to just resolve it precisely internally? I
assume it could be done by something like push_macroing all current macros,
figuring out which builtin macros to use for the header unit, then when you
are done processing that header merge the pushed macros with the current
macros using the rules for modules. Is that infeasably hard or not work for
some reason?