<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 10 June 2017 at 00:20, Boris Kolpackov via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> writes:<br>
<br>
> Clang supports mixing Modules TS modules with header modules. Header<br>
> modules support exporting macros. Therefore, because "import foo;" might<br>
> import a module that exports a macro, it must be available during<br>
> preprocessing.<br>
<br>
</span>This causes a bit of a chicken and egg problem for us: we analyze the<br>
preprocessed output to discover which modules are required but need to<br>
know the required modules before preprocessing.<br>
<br>
I could remove the -fmodules-ts but that's not ideal since this option<br>
could conceivably alter predefined macros (like __cpp_modules).<br>
<br>
Is there a way to disable this "header modules" support and get a pure<br>
Modules TS semantics? If not, do you think such a mode could be added?<br></blockquote><div><br></div><div><div>That wouldn't help if we want to give Modules TS modules the ability to export macros as an extension (which it seems like we probably would want to do). But... at that point, the problem is fundamental: an earlier-imported module could export a macro that is expanded later and generates a module import. Given that your analysis strategy is incompatible with such an extension anyway, I think your request for a mode that sets up the modules-specific build configuration but doesn't handle 'import' in the preprocessor is reasonable.</div><div><br></div><div>Would you be interested in writing a patch for this?</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We could have only enabled "header modules" if both -fmodules-ts and<br>
-fmodules are specified, but that ship might have already sailed.</blockquote><div><br></div><div>It wouldn't be too late for that. The command-line interface for header modules has been around for a long while, have been used in numerous build systems, and would be painful to change at this point, but the same is not true for the modules TS command-line interface. But we would still have the issue that we explicitly permit a Modules TS import to import a (header) module that exports macros, so I don't think this solves your problem.</div></div></div></div>