Multiple diagnostics can be caused by the same unresolved name or incomplete type,
especially if the code is copy-pasted without #includes. The cache can avoid making
repetitive index requests, and thus reduce latency and allow more diagnostics to be
fixed (we limit the number of index requests for each parse).
Details
- Reviewers
sammccall - Commits
- rGb355802910da: [clangd] Cache include fixes for diagnostics caused by the same unresolved name…
rCTE354268: [clangd] Cache include fixes for diagnostics caused by the same unresolved name…
rL354268: [clangd] Cache include fixes for diagnostics caused by the same unresolved name…
Diff Detail
- Repository
- rCTE Clang Tools Extra
- Build Status
Buildable 28141 Build 28140: arc lint + arc unit
Event Timeline
clangd/IncludeFixer.cpp | ||
---|---|---|
130 | oops - this seems broken (in both the old and new form). Symbol is a shallow reference, and it's not valid after lookup() returns. We can fix here or separately... one option to fix is the ResolvedSymbol struct suggested above. (The fuzzyFind case looks ok) | |
clangd/IncludeFixer.h | ||
85 | This seems pretty messy (the assumption that Fix depends only on the index lookup). What would we need to store to calculate Fix? | |
90 | DenseMap<SymbolID, ...>? |
clangd/IncludeFixer.h | ||
---|---|---|
85 | Yeah, surely this was too hacky ;) Instead of a new struct, how about simply storing SymbolSlabs? We are already building symbol slabs for fuzzy find results. And there are some helpers that take only Symbol. WDYT? |
SymbolSlab is much cleaner, nice!
clangd/IncludeFixer.cpp | ||
---|---|---|
136–137 | extract a function that maps SymbolID -> const SymbolSlab& and takes care of the caching? | |
clangd/IncludeFixer.h | ||
86 | nit: maybe drop the parenthetical here? I think it's more confusing than enlightening. ("assuming" can mean either "and we assume" or "if" in this context. Also it's not clear there's a better behavior even if results did change and queries are free.) |
This seems pretty messy (the assumption that Fix depends only on the index lookup).
It saves some code now at the expense of being magic. If we want to e.g. insert qualifiers too, I worry it's going to (stop us || return incorrect cached results || lead to unneccesary cache misses) depending on what we do.
What would we need to store to calculate Fix?
Maybe a struct ResolvedSymbol with {scope, name, inserted header}? (or even the edit to insert the header)
If it's not hugely complicated, that seems both cleaner and more extensible - wdyt?