[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