<span>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. </span><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 6, 2019, 17:29 Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com">ben.boeckel@kitware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Mar 06, 2019 at 16:16:06 -0500, Steve Downey wrote:<br>
> For an #include you can run the preprocessor exactly. For an import you, at<br>
> least in theory, need either know how the bmi was created, or do the<br>
> processing implicitly and then import the BMI. If I understand correctly,<br>
> this is why clang will track the flags used in implicit bmi creation,<br>
> because they might change and make the BMI incorrect.<br>
<br>
That mismatch is an error for compile time. Scanning can assume the<br>
`import` will succeed because if the assumption is invalid, it isn't<br>
going to compile anyways and something will force the scan to happen<br>
again whether it is command line changing or input file contents<br>
changing.<br>
<br>
--Ben<br>
</blockquote></div>