<div dir="ltr">Thanks! followed up on the bug.</div><br><div class="gmail_quote"><div dir="ltr">On Sun, Oct 21, 2018 at 7:09 PM Matt Asplund <<a href="mailto:mwasplund@gmail.com">mwasplund@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><a class="gmail_plusreply" id="m_-2071467295813844486plusReplyChip-0" href="mailto:dblaikie@gmail.com" target="_blank">+David Blaikie</a> Since you were discussing this with me before.<br></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Oct 21, 2018 at 7:08 PM Matt Asplund <<a href="mailto:mwasplund@gmail.com" target="_blank">mwasplund@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I believe there is an inherent issue with how clang uses the precompiled header structure to implement a module interface definition. When linking against this module file clang brings in all of the header lookup, which I can fix by forcing ModulesTS to not include the external source. However, it feels like I am fighting the pcm to ignore already included files and previously defined symbols that should have global module linkage. From reading the spec it feels like the pcm file should ONLY contain the symbols available from name lookup from module interface purview to implementation purview as well as exported symbols that are imported. <div><br></div><div>Side note: As I try to track down these issues it seems odd that ModulesTS is forcing Modules to be turned on as well. Would it be easier to keep Clang Modules entirely separate from ModulesTS?</div><div><br></div><div>-Matt</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Oct 21, 2018 at 5:54 PM Matt Asplund <<a href="mailto:mwasplund@gmail.com" target="_blank">mwasplund@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This was discussed in a separate thread, but got lost in the discussion. <div><br></div><div>I am currently working on porting a legacy project over to using the new modules-ts and would hit the issue linked in <b style="font-family:Verdana,sans-serif;font-size:16.25px;font-weight:700"><a href="https://bugs.llvm.org/show_bug.cgi?id=39206" style="color:rgb(102,51,102);font-family:Verdana,sans-serif;font-size:16.25px;font-weight:700" target="_blank">Bug 39206</a> </b>I could not find any explicit section of the spec that says the processor should be effected by compilation of a module, however clang seems to be hiding macros that were defined in included header files that were also included in the interface module. </div><div><br></div><div>If this is indeed a bug I would also appreciate help pointing in the right direction in the code. I have spent some time trying to find where the actual check is occurring that is hiding macros, but am at a loss.</div><div><br></div><div>Thanks,</div><div>Matt</div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>