[Tooling] [isocpp-modules] Dependency information for module-aware build tools
Steve Downey
sdowney at gmail.com
Wed Mar 6 23:42:37 CET 2019
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 kitware.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/tooling/attachments/20190306/d890854b/attachment.html
More information about the Tooling
mailing list