PR23929 - Code completion for macros broken when modules enabled

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.

(Apart from code completion, this also affects a few other features that want to know all names provided by a particular header file. coughSwiftcough)

Thanks,
Jordan

Hi, Richard. Thanks for all your improvements to modules this year! I just
filed PR23929 <https://llvm.org/bugs/show_bug.cgi?id=23929&gt;, 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.

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.)

I think this should be a straightforward fix; if you have problems, let me
know and I'll tackle it. Sorry for breaking you :slight_smile:

(Apart from code completion, this also affects a few other features that

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?

Jordan

macros.patch (2.04 KB)

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.

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.)

I think this should be a straightforward fix; if you have problems, let me know and I’ll tackle it. Sorry for breaking you :slight_smile:

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?

LGTM

(I think we already have test coverage for macro name visibility in code completion.)

Sounds good. Committed as r240571. Thanks for the help!

Jordan