I don't bother mirroring the full capabilities struct, just parse the
bits we care about. I'll send a new patch to use this approach elsewhere too.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
clangd/ClangdLSPServer.cpp | ||
---|---|---|
338 ↗ | (On Diff #169481) | What would you think about emitting two commands in this case? First the edit and then the command. I believe LSP doesn't specify any ordering on how the commands returned should be executed by the client, so I am OK with current state as well. Just wanted to know if there were any other concerns. |
350 ↗ | (On Diff #169481) | It seems we only prepend title with Apply fix when we fallback, I believe it would be better to add them in CodeAction instead? |
355 ↗ | (On Diff #169481) | I believe this comment is misleading, do we perform any location check? Maybe change that to say "requested file"? |
clangd/Protocol.h | ||
390 ↗ | (On Diff #169481) | What is the reason behind this one? Is it because clients must handle unknown items on their own and fallback to a default one? Since that default is client specific, behavior might change from client to client. I agree that clients should be up-to-date with the specs and handle all kinds of items but these might still create confusions during the transition period. For example, ycmd decided to fallback to None instead of Text when they don't know about a symbolkind of a completion item, so users will get to see "File" for the include insertions on both folders and files but when they update to a newer clangd, they will start to see "File" for files and "None" for directory elements. Which I believe might create confusion, but we could still fallback to File for those elements(if we handled them within clangd) and user experience would neither worsen or improve. (Currently ycmd's symbolkindcapabilities are actually up-to-date with specs, so this issue wouldn't happen. Just wanted to make my point clearer). |
update comment
clangd/ClangdLSPServer.cpp | ||
---|---|---|
338 ↗ | (On Diff #169481) | That doesn't have the right semantics. Multiple commands returned from textDocument/codeAction are alternatives that the user should select between, whereas having both an edit and a command means they should be performed atomically as one action. (This never actually happens as we don't emit such actions, added a comment) |
350 ↗ | (On Diff #169481) | The CodeAction has a slot to describe the type of action: if the client wants to prepend "Quick Fix: " or so it can. |
355 ↗ | (On Diff #169481) | Updated the comment. |
clangd/Protocol.h | ||
390 ↗ | (On Diff #169481) | Sorry, I don't really understand the question. Are you talking about the default for codeActionLiteralSupport? The protocol says servers must send Commands unless the client indicates support for CodeActions. There's no room for a different default here. Or flattening of other properties? That will have no effect on logic, it just simplifies the code (see D53266). |
LGTM, thanks!
clangd/ClangdLSPServer.cpp | ||
---|---|---|
338 ↗ | (On Diff #169481) | Oh I see, nvm then. |
350 ↗ | (On Diff #169481) | OK, that makes sense. |
clangd/Protocol.h | ||
390 ↗ | (On Diff #169481) | Ok, I thought we were also going to throw away the "valueset"s and just keep whether the client has the capability(and therefore graceful handling) or not. |
clangd/Protocol.h | ||
---|---|---|
390 ↗ | (On Diff #169481) | Ah, no. That might actually be a better complexity tradeoff, but I'm not proposing changing the existing behavior at the moment. On the other hand, for CodeActions themselves, this patch does rely on the client handling arbitrary CodeActionKinds, it doesn't look at exactly which ones the client understands. |