================ @@ -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:
Talked about this offline a good amount. The problem here is the `lookupModule` logic in this case, and the symlink-ness is somewhat tangential. The relocation check fails within the single scan during the compilation of `Foo_Private`'s module, where it loads the symlink module `Mod` transitively through `Foo`'s PCM. When this happens, the CompilerInstance for `Foo_Private` has not already loaded `Mod`'s modulemap in any way. When the relocation check happens, it tries to search for the module by name, but that fails because there is no matching search path directory `Mod` vs `module`. So the module never actually relocated, but there is no way to find the module by a `@import Mod;` with the current search paths. One way to handle this case is to look up the module via how the importer resolved the module, but that would potentially be expensive since that would mean we do a relocation check for each path to the same module. I'm not convinced that's necessary right now, as it is more common to expect that a module is resolvable by name. I did add a new test to check the behavior when the search resolution changes between scans. https://github.com/llvm/llvm-project/pull/183328 Through this exercise, I learned that the PCM context hash uses a canonical path for the modulemap, but the modulemap recorded in the PCM does not. I can align those as a follow-up patch. https://github.com/llvm/llvm-project/pull/181836 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
