This is an archive of the discontinued LLVM Phabricator instance.

Lex: Migrate HeaderSearch::LoadedModuleMaps to FileEntryRef
Changes PlannedPublic

Authored by dexonsmith on Dec 9 2020, 2:48 PM.

Details

Summary

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.

Diff Detail

Event Timeline

dexonsmith created this revision.Dec 9 2020, 2:48 PM
dexonsmith requested review of this revision.Dec 9 2020, 2:48 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 9 2020, 2:48 PM
dexonsmith updated this revision to Diff 310713.Dec 9 2020, 4:28 PM

I must have just been building clangLex before, since I missed (until now) updating the other API users.

This revision is now accepted and ready to land.Dec 10 2020, 7:22 AM
thakis added a subscriber: thakis.Dec 14 2020, 4:32 PM

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?

http://45.33.8.238/win/29852/step_7.txt

The revert helped, check-clang is no longer failing on Windows.

Thanks for reverting; sorry I missed your email.

There were also two Windows bots that emailed me yesterday afternoon, I just missed them somehow :/.

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;
 ^
dexonsmith reopened this revision.Dec 15 2020, 5:58 PM

Reopening for now, although I haven't updated the patch yet, or quite tracked down the issue.

This revision is now accepted and ready to land.Dec 15 2020, 5:58 PM
dexonsmith planned changes to this revision.Dec 15 2020, 5:58 PM

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.