Migrate HeaderSearch::LoadedModuleMaps and a number of APIs over to
FileEntryRef. This should have no functionality change. Note that two
FileEntryRefs hash the same if they point at the same FileEntry.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I must have just been building clangLex before, since I missed (until now) updating the other API users.
One of the changes in https://github.com/llvm/llvm-project/compare/6af2c4ca9bd...2733a5a5b44 broke check-clang on windows. This change looks the most likely to me. Can you take a look?
There were also two Windows bots that emailed me yesterday afternoon, I just missed them somehow :/.
- http://lab.llvm.org:8011/#/builders/119/builds/1381 (llvm-clang-win-x-aarch64)
- http://lab.llvm.org:8011/#/builders/60/builds/1175 (llvm-clang-win-x-armv7l)
FTR, the test that fails is clang/test/VFS/real-path-found-first.m, which was added in 5de00f3b56805c7e980f049ceb3f166f8c69cec0 (Stopgap fix for finding module for a file mapped in the VFS). It fails on final -cc1 call at line 64, which is the reentry for "within a module build":
# command stderr: <stdin>:1:2: fatal error: module 'import_some_frame' was built in directory 'C:/src\llvm-project\clang\test\VFS\Inputs' but now resides in directory 'C:\src\llvm-project\out\gn\obj\clang\test\VFS\Output\real-path-found-first.m.tmp' @import import_some_frame; ^
Reopening for now, although I haven't updated the patch yet, or quite tracked down the issue.
Given that 5de00f3b56805c7e980f049ceb3f166f8c69cec0 updates the return value of FileEntry::getDir as a (self-described) hack, and FileEntryRef::getDir won't be similarly updated, it's somewhat reasonable that this would break... but I still need to understand the exact scenario here before I can fix it.