This is an archive of the discontinued LLVM Phabricator instance.

[clang][lex] Use `ConstSearchDirIterator` in lookup cache
ClosedPublic

Authored by jansvoboda11 on Feb 14 2022, 7:32 AM.

Details

Summary

This patch starts using the new iterator type in LookupFileCacheInfo.

Depends on D117566.

Diff Detail

Event Timeline

jansvoboda11 requested review of this revision.Feb 14 2022, 7:32 AM
jansvoboda11 created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 14 2022, 7:32 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
ahoppen added inline comments.Feb 14 2022, 9:26 AM
clang/lib/Lex/HeaderSearch.cpp
710

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?

982

What’s the reason that this can’t be? The current lambda-based implementation looks a little over-complicated to me. But maybe I’m missing something.

ConstSearchDirIterator NextIt = ItCopy;
++NextIt;

or even something equivalent to

ConstSearchDirIterator NextIt = std::next(ItCopy);
jansvoboda11 added inline comments.Feb 15 2022, 12:11 AM
clang/lib/Lex/HeaderSearch.cpp
710

This should really call to searchDirIdx(). That will be updated when we switch to different storage type in a follow up commit.

Since we're using forward iterators, calling std::distance would be O(n) instead of the current O(1).

982

It can be both. I didn't like the former for its verbosity, but std::next should do the trick, thanks!

Use std::next and ConstSearchDirIterator::Idx.

jansvoboda11 added inline comments.Feb 15 2022, 12:14 AM
clang/lib/Lex/HeaderSearch.cpp
710

(Used ConstSearchDirIterator::Idx for now, but will refactor this with the new storage layout in a follow-up.)

ahoppen accepted this revision.Feb 15 2022, 12:48 AM
This revision is now accepted and ready to land.Feb 15 2022, 12:48 AM
jansvoboda11 edited the summary of this revision. (Show Details)Feb 15 2022, 1:38 AM
This revision was landed with ongoing or failed builds.Feb 15 2022, 2:04 AM
This revision was automatically updated to reflect the committed changes.
sberg added subscribers: rnk, sberg.Mar 22 2022, 8:20 AM

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

Herald added a project: Restricted Project. · View Herald TranscriptMar 22 2022, 8:20 AM

Thanks for reporting this (also reported here: https://github.com/llvm/llvm-project/issues/54426). I have a fix up for review here: D122237.