- No longer store the diagnostic fixits in the clangdLSPServer
- When propagating the fixit via the code action, we use the Diag information stored in the ParsedAST (in clangdServer.cpp)
Details
- Reviewers
kadircet - Commits
- rGf4f6c229bde8: [clangd] Refine the workflow for diagnostic Fixits.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clangd/ClangdServer.cpp | ||
---|---|---|
671 | this is tricky indeed and conceptually really hard to achieve inside ClangdServer layer. what about keeping the cache in ClangdLSPServer, but changing the format? Similar to TweakRef, we now have a DiagRef, which is ClangdServer-native. So we can keep a cache from (FilePath, clangd::Diagnostic) to clangd::DiagRef, and pass those DiagRefs to ClangdServer and make sure we're doing the search for sure on the right domain here? this also gives us the flexibility to change the definition of a DiagRef in the future. | |
683 | we can have quick fix kind tweaks too (e.g. populate switch) | |
713–714 | can you also move this counter to global scope and use it in ::codeAction too? | |
clang-tools-extra/clangd/ClangdServer.h | ||
384 | maybe a more structured output can be useful here: struct CodeActionResult { std::string Version; // Version of content results belong to. struct QuickFix { DiagRef D; // Diagnostic being addressed by the fix. Fix F; }; std::vector<QuickFix> QuickFixes; std::vector<TweakRef> TweakRefs; }; |
address review comments.
clang-tools-extra/clangd/ClangdServer.cpp | ||
---|---|---|
671 | I'm not a fan of keeping a cache in ClangdLSPServer, I'd like to remove it entirely. What do you think about this alternative?
The downside here is that we have to pay O(N * cost of mainMessage) to find a matched diagnostic. | |
683 | oops, I weren't aware of that, removed. | |
713–714 | I added a similar local counter in codeAction method, since this method is being deprecated, and removed eventually (it doesn't seem too make much sense to use a shared counter) | |
clang-tools-extra/clangd/ClangdServer.h | ||
384 | good idea, also keep symmetry with the CodeActionInputs |
Use the mainMessage to find the corresponding ClangdServer diagnostics.
clang-tools-extra/clangd/ClangdServer.cpp | ||
---|---|---|
671 | I updated the patch with the mainMessage approach, please take a look. |
clang-tools-extra/clangd/ClangdServer.cpp | ||
---|---|---|
671 | i believe this still runs into the same conceptual problems. we're trying to imitate the logic done by clangdlspserver when converting a clangd-native diagnostic into an lsp-diagnostic and all of this will break as soon as there's a change in that logic. so if we want to go down that path, the best option would be to call toLSPDiagevery time here and make sure we imitate that logic properly (e.g. right now we're relying on the ranges not being remapped because we only store fixes for the main file diagnostics). but i feel like this is unnecessary cost both at runtime but also as code-complexity wise. this is ~the same as the data/args we publish with commands. it's just unfortunate that data field in diagnostic didn't exist pre LSP 3.16, hence we can't rely on it without breaking compatibility with some old clients (hopefully we can do that one day), hence instead of clients keeping this identifier around, I am merely suggesting to keep this alive on the server side. as conceptually this is the only layer that can do the mapping back and forth. | |
713–714 | sorry i am confused. the counter has nothing to do with how we generated a tweak. it's merely counting number of times a tweak was returned. hence we don't need a new one (if a code action Bar was made available either through a call to ::enumerateTweaks or ::codeAction we should increment the same counter. clients won't be invoking both at the same time, they'll be using one or the other). |
add LSPServer cache back and repurpose for lsp <=> naive diagnostic mapping, per offline discussion.
clang-tools-extra/clangd/ClangdLSPServer.cpp | ||
---|---|---|
1009–1018 | we're already making a copy of Params.context.diagnostics when creating the CB. so you might as well have a std::map<ClangdServer::DiagRef, clangd::Diagnostic> RefsToDiags; and get rid of the extra index conversions. | |
clang-tools-extra/clangd/ClangdLSPServer.h | ||
237 | instead of storing clangd::Diagnostic as the key, can we have a DiagnosticKey struct here (we can have a helper diagKey(const clangd::Diagnostic&) -> DiagnosticKey)? to make sure we don't get into trouble if there are too many "big" diagnostics :) that way we can also get rid of the custom comparator. |
address comments
- introduce DiagKey for the caching map
- get rid of extra index conversion
instead of storing clangd::Diagnostic as the key, can we have a DiagnosticKey struct here (we can have a helper diagKey(const clangd::Diagnostic&) -> DiagnosticKey)? to make sure we don't get into trouble if there are too many "big" diagnostics :)
that way we can also get rid of the custom comparator.