Clangd currently doesn't cache any indexing failures, which results in
retrying those failed files even if their contents haven't changed.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 34122 Build 34121: arc lint + arc unit
Event Timeline
Change looks sensible, just wondering if we should keep the main-file symbols/refs, and whether we can simplify/unify a bit.
clang-tools-extra/clangd/index/Background.cpp | ||
---|---|---|
361 | couldn't we have a much more unified handling of error/non-error case, by simply dropping all non-main-file shards at this point? (in case of error) In theory we're processing them a bit, but it practice it seems like they're empty. | |
clang-tools-extra/clangd/index/IndexAction.cpp | ||
154–155 | I'm pretty sure the include graph is basically good in this case (up to the possibly-missing files). So we should at least send that, so invalidation works (or can work in the future). Also, we agreed not to overwrite the symbols for the included headers' shards, but what about the main file itself? Surely better to have something than nothing. (The "something" is roughly clang's recovery, which is what AST-based completions rely on anyway) More generally, do we need filtering logic at both ends? | |
155 | comment belongs in the if, not the else |
clang-tools-extra/clangd/index/IndexAction.cpp | ||
---|---|---|
154–155 | Left the error detection behavior same(checking for uncompilable errors) |
Thanks!
clang-tools-extra/clangd/index/Background.cpp | ||
---|---|---|
140 | (I'd suggest inlining this again as it's fairly clear straight-line code, but up to you) | |
313 | Maybe add a FIXME that we should store other contents too, but only if the current shard contents are missing or also had errors. | |
500 | why do we want to skip (maybe) rebuilding the index in this case? | |
500 | I think this is now a "warning" rather than an error, maybe log something like "failed to compile {Cmd.Filename}, index may be incomplete" |
clang-tools-extra/clangd/index/Background.cpp | ||
---|---|---|
313 | I agree with storing contents if they are missing, but does it make sense to replace one broken shard information with other? | |
500 | actually, we don't want to skip. I had written that part with the old assumption; that is, "we don't get any symbol info when compilation fails". |
Still LG
clang-tools-extra/clangd/index/Background.cpp | ||
---|---|---|
313 | I'd say it makes sense if the content has changed. i.e: bool replace() { if old == null return true if !new.isTU && new.errors && !old.errors return false return new.digest != old.digest } (don't let this block you landing it, up to you) |
(I'd suggest inlining this again as it's fairly clear straight-line code, but up to you)