<p dir="ltr">On 24 Jun 2015 10:00 am, "Jordan Rose" <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:<br>
><br>
><br>
>> On Jun 23, 2015, at 14:15 , Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
>><br>
>> On Tue, Jun 23, 2015 at 10:53 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:<br>
>>><br>
>>> Hi, Richard. Thanks for all your improvements to modules this year! I just filed PR23929, which shows how code completion is no longer finding macros that come from modules. Any idea what should be changed here? If you don't have time to fix this I'm happy to be the one who actually codes it up, but at the moment I'm not even quite sure what piece is missing.<br>
>><br>
>><br>
>> Identifiers that have macro names imported from modules get lazily updated, and macro_begin isn't triggering enough updating to produce a complete map. The easiest thing to do would be to walk the ModuleMacros map from within macro_begin, and add entries for each identifier with any module macros to the MacroMap in the CurSubmoduleState. (Alternatively, you could change macro_begin/macro_end to return iterators over the identifier table that filter out non-macro identifiers. Either way is a little wasteful, but avoiding that waste would require implementing a rather fancy iterator, which seems like overkill for this problem.)<br>
>><br>
>> I think this should be a straightforward fix; if you have problems, let me know and I'll tackle it. Sorry for breaking you :-)<br>
><br>
><br>
> Ah, you're right, it was that simple. How does the attached patch look? Do you think I need to beef up the tests to account for visible vs. non-visible modules, or do you think this is fine to commit as is?</p>
<p dir="ltr">LGTM</p>
<p dir="ltr">(I think we already have test coverage for macro name visibility in code completion.)</p>
<p dir="ltr">> Jordan<br>
><br>
><br>
><br>
><br>
</p>