FileIndex was built out of threadsafe components, so update() didn't have data
races, but wasn't actually correct.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
LGTM, thanks!
clang-tools-extra/clangd/index/FileIndex.cpp | ||
---|---|---|
270 | Bumping the version in update and just exposing it in buildIndex feels more natural, WDYT? Might even enable us to get rid of some redundant resets (not that it is expensive ..), imagine a sequencing like:
even though both build the same index, they got different version numbers hence both will reset the current index. | |
clang-tools-extra/clangd/index/Symbol.h | ||
190 | i suppose this is for testing::SizeIs right? |
clang-tools-extra/clangd/index/FileIndex.h | ||
---|---|---|
97 | oh and also maybe use size_t ? as there's only one (well three actually, if you count both preamble and main-file index separately, and one in background-index) instance of FileSymbols for a single clangd instance, hence we could in theory bump this number with every keystroke :/ I suppose 4 bytes is also far from any practical limits, but pushing it as far as possible wouldn't hurt? |
oh and also maybe use size_t ?
as there's only one (well three actually, if you count both preamble and main-file index separately, and one in background-index) instance of FileSymbols for a single clangd instance, hence we could in theory bump this number with every keystroke :/
I suppose 4 bytes is also far from any practical limits, but pushing it as far as possible wouldn't hurt?