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