[PATCH] D119721: [clang][lex] Use `ConstSearchDirIterator` in lookup cache

Jan Svoboda via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Feb 15 00:11:30 PST 2022


jansvoboda11 added inline comments.


================
Comment at: clang/lib/Lex/HeaderSearch.cpp:710
+  CacheLookup.HitIt = HitIt;
+  noteLookupUsage(&*HitIt - &*search_dir_begin(), Loc);
 }
----------------
ahoppen wrote:
> 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?
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).


================
Comment at: clang/lib/Lex/HeaderSearch.cpp:982
 
+  ConstSearchDirIterator NextIt = [](auto ItCopy) { return ++ItCopy; }(It);
+
----------------
ahoppen wrote:
> 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);
> ```
It can be both. I didn't like the former for its verbosity, but `std::next` should do the trick, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119721/new/

https://reviews.llvm.org/D119721



More information about the cfe-commits mailing list