================
@@ -10,6 +10,8 @@
// RUN: sed -e "s|DIR|%/t|g" %t/cdb.json.in > %t/cdb.json
// RUN: ln -s module %t/include/symlink-to-module
+// RUN: touch %t/session.timestamp
----------------
cyndyishida wrote:
You may be wondering why this test was changed. This was my not-so-great way of
handling a problem where the module has different modulemaps through a symlink,
which triggers the relocation check to fail within a single compilation. This
basically skips relocation checks in a single compilation. This also passes
fine in a normal implicit module build because the modulemap files get resolved
through inode resolution.
I initially thought this was an invalid use, but I was convinced otherwise,
given that it seems pretty easy to end up in this state as a client of external
interconnected libraries like an SDK.
When `clang-scan-deps` scans a TU that reaches the same module map file via two
different include paths:
1. canonical (include/module/module.modulemap) and
2. through a symlinked directory (include/symlink-to-module/module.modulemap)
It builds the affected module `Mod` twice with different context hashes,
because `ClangModuleMapFile` in `ModuleDepCollector` is set from
`FileEntryRef::getNameAsRequested()`, which returns the path as it was first
requested rather than a stable canonical path.
The two PCMs then conflict during the scan. When `Foo_Private` is loaded and
its imported `Foo` pcm references the canonical path for `Mod`'s pcm,
`ReadModuleMapFileBlock` in ASTReader calls `lookupModule("Mod")` to validate
it. But `Mod`'s `Module*` object was populated from the
symlink-path PCM, and its DefinitionLoc has no `FileID` in the current
`SourceManager` because the canonical module map was never parsed into it.
`getModuleMapFileForUniquing` returns null, and the relocation check fires.
This touches on the abstraction layers of the scanner's vfs that I don't have
good suggestions for at the moment.
https://github.com/llvm/llvm-project/pull/181836
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
