C++ Logo

sg15

Advanced search

Re: [Tooling] [isocpp-modules] Dependency information for module-aware build tools

From: Steve Downey <sdowney_at_[hidden]>
Date: Wed, 6 Mar 2019 17:42:37 -0500
You can assume it succeeds, but the compiler can't know what macros will be
exported from a header unit. However, it's also ill-formed to have a module
translated in two different ways in a project, or to depend on an #include
being different than a header module in the same build. The question is if
it's detectable.

On Wed, Mar 6, 2019, 17:29 Ben Boeckel <ben.boeckel_at_[hidden]> wrote:

> On Wed, Mar 06, 2019 at 16:16:06 -0500, Steve Downey wrote:
> > For an #include you can run the preprocessor exactly. For an import you,
> at
> > least in theory, need either know how the bmi was created, or do the
> > processing implicitly and then import the BMI. If I understand correctly,
> > this is why clang will track the flags used in implicit bmi creation,
> > because they might change and make the BMI incorrect.
>
> That mismatch is an error for compile time. Scanning can assume the
> `import` will succeed because if the assumption is invalid, it isn't
> going to compile anyways and something will force the scan to happen
> again whether it is command line changing or input file contents
> changing.
>
> --Ben
>

Received on 2019-03-06 23:42:53