This patch starts using the new iterator type in LookupFileCacheInfo.
Depends on D117566.
Paths
| Differential D119721
[clang][lex] Use `ConstSearchDirIterator` in lookup cache ClosedPublic Authored by jansvoboda11 on Feb 14 2022, 7:32 AM.
Details
Diff Detail
Event Timelinejansvoboda11 created this revision.
This revision is now accepted and ready to land.Feb 15 2022, 12:48 AM This revision was landed with ongoing or failed builds.Feb 15 2022, 2:04 AM Closed by commit rG17c9fcd6f6fc: [clang][lex] Use `ConstSearchDirIterator` in lookup cache (authored by jansvoboda11). · Explain Why This revision was automatically updated to reflect the committed changes. Comment Actions I started to experience Clang crashing when building Firebird (as part of building LibreOffice) in clang-cl mode on Windows, and I think it is due to this change in combination with D2733 by @rnk: When HeaderSearch::LookupFile exits through one of the if (checkMSVCHeaderSearch... branches introduced in D2733, it does not update CacheLookup.HitIt (through one of the calls to cacheLookupSuccess or via the "Otherwise, didn't find it" step at the end of the function), even though it already may have done the "We will fill in our found location below, so prime the start point value" step of calling CacheLookup.reset. That means that a later call to HeaderSearch::LookupFile can go into the if (!SkipCache && CacheLookup.StartIt == NextIt) true branch, set It = CacheLookup.HitIt to an invalid iterator (the default HitIt = nullptr value), and then assert/crash when dereferencing that invalid It. Which was not an issue before this change, as the initial HitIdx = 0 was not an invalid value, so i = CacheLookup.HitIdx never caused i to become invalid. I locally worked around this in my build with - if (!SkipCache && CacheLookup.StartIt == NextIt) { + if (!SkipCache && CacheLookup.StartIt == NextIt && CacheLookup.HitIt) { which seems to work well, but I'm not sure what the best real fix would be. (D2733 stated "I believe the correct behavior here is to avoid updating the cache when we find the header via MSVC's search rules.") Comment Actions Thanks for reporting this (also reported here: https://github.com/llvm/llvm-project/issues/54426). I have a fix up for review here: D122237.
Revision Contents
Diff 408733 clang/include/clang/Lex/HeaderSearch.h
clang/lib/Lex/HeaderSearch.cpp
|
I haven’t looked into this in total details but &* looks a little awkward to me. Dereference a pointer/iteration and then get its pointer value back?
Wouldn’t this hit the same issue that we saw before if serach_dir_begin is allocated in a different bump allocator begin than HitIt?
If possible, would std::distance communicate the intent more clearly?