In practice, opening Foo.h will still often result in Foo.cpp making the
second index build instead of the first, as the rebuild policy doesn't
know to wait.
Details
Details
- Reviewers
kadircet - Commits
- rG0f7146db9b2c: [clangd] Prioritize indexing of files that share a basename with the open file.
rL365888: [clangd] Prioritize indexing of files that share a basename with the open file.
rCTE365888: [clangd] Prioritize indexing of files that share a basename with the open file.
Diff Detail
Diff Detail
- Repository
- rL LLVM
Event Timeline
clang-tools-extra/clangd/TUScheduler.h | ||
---|---|---|
145 ↗ | (On Diff #209273) | Is the Adds \p File to a list of tracked files if ... part got deleted intentionally? |
clang-tools-extra/clangd/index/Background.h | ||
106 ↗ | (On Diff #209273) | maybe store a QueuePriority instead of unsigned? Also it seems like the enum belongs to BackgroundQueue, rather then BackgroundIndex |
clang-tools-extra/clangd/TUScheduler.h | ||
---|---|---|
145 ↗ | (On Diff #209273) | It's now covered by the last line. |
clang-tools-extra/clangd/index/Background.h | ||
106 ↗ | (On Diff #209273) | This is a layering thing: the queue knows about tasks and tags, but doesn't know about TUs, filenames, or active files. I don't plan on actually splitting this header out, but it helps me reason about the code. Do you think it's too abstract? |
clang-tools-extra/clangd/index/Background.h | ||
---|---|---|
106 ↗ | (On Diff #209273) | Nah that's OK. Queue has become more priority aware after this patch, previously it only cared about the priority within the task struct. Therefore it become confusing to see the enum in BackgroundIndex itself. |