[SourceManager] Skip module maps when searching files for macro arguments

[jkorous]

Summary

I have a test-case for this issue but it's pretty convoluted - we basically found this because clang_annotateTokens in libclang wasn't
attaching RefDeclExpr to macro argument identifiers. This was happening for a source file that includes module that has external submodule defined in its modulemap.

[jkorous]

Ping

[arphaman]

Could you please add a comment stating why it's necessary to skip the module map files? Is the problem caused by the module map file that's included in the include hierarchy when it's an external module?

Is there any way to reduce the convoluted test-case and add it to the patch?

[jkorous]

I could be missing something but it seemed that skipping module maps when we're searching for source locations is obviously the right thing to do. Don't really know if repeating what the code does in the comment would bring any value.

The reproducer I have is at libclang API level and involves module and external submodule which seems pretty far (both conceptually and code-path-wise) from macro args cache initialization.

The reproducer dir looks like this:

> find .
.
./modulefoo
./modulefoo/module.map
./modulefoo/dyld.h
./modulefoo/dyld.modulemap
./modulefoo/loaderfoo.h
./code.c

> cat code.c
#include "modulefoo/loaderfoo.h"
#define FOO234878786(a) (a + a)
const int a = 1;
const int b = FOO234878786(a);

> cat modulefoo/module.map
module MachOFoo [system] [extern_c] {

  extern module dyld "dyld.modulemap"

  module loaderfoo {
    header "loaderfoo.h"
    export *
  }

}

And this is the way to see observable difference:

c-index-test -test-annotate-tokens=code.c:4:1:4:100 code.c -fmodules -fmodules-cache-path=/tmp/mcp -x c

[jkorous]

This comment was removed by jkorous.

[arphaman]

Okay, that's fair. Is there any way to trigger the computeMacroArgsCache outside of libclang, to create a clang-specific test case?

[jkorous]

Attempt to write a unit test - so far can't reproduce even with unpatched master :(

The only place where SourceManager::computeMacroArgsCache is used is SourceManager::getMacroArgExpandedLocation.

I literally just copied and slightly modified existing unit-test which doesn't work - any help would be appreciated.

[jkorous]

Friendly ping.
I'd like to land this sooner than later - I agree it'd be great to have a regression test but my (possibly biased) opinion is that the change is also simple and obvious enough that we could land it without a test.

[arphaman]

Hmm if this unit tests doesn't reproduce it then you don't need to add it. But no further objections from me on this change.

[dexonsmith]

clang/lib/Basic/SourceManager.cpp

1794–1799

It seems unintentinoal to copy out the FileInfo here. Should this be a reference?

auto &File = Entry.getFile();

clang/lib/Basic/SourceManager.cpp

if (ID > 0) {
       return;
     }
 
     bool Invalid = false;
     const SrcMgr::SLocEntry &Entry = getSLocEntryByID(ID, &Invalid);
     if (Invalid)
       return;
     if (Entry.isFile()) {
-      SourceLocation IncludeLoc = Entry.getFile().getIncludeLoc();
+      auto File = Entry.getFile();
+      if (File.getFileCharacteristic() == C_User_ModuleMap ||
+          File.getFileCharacteristic() == C_System_ModuleMap)
+        continue;
+
+      SourceLocation IncludeLoc = File.getIncludeLoc();
       bool IncludedInFID =
           (IncludeLoc.isValid() && isInFileID(IncludeLoc, FID)) ||
           // Predefined header doesn't have a valid include location in main
           // file, but any files created by it should still be skipped when
           // computing macro args expanded in the main file.
           (FID == MainFileID && Entry.getFile().Filename == "<built-in>");
       if (IncludedInFID) {
         // Skip the files/macros of the #include'd file, we only care about