This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Send CodeAction responses to textDocument/codeAction (LSP 3.8)
ClosedPublic

Authored by sammccall on Oct 12 2018, 1:10 PM.

Details

Summary

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.

Diff Detail

Repository
rL LLVM

Event Timeline

sammccall created this revision.Oct 12 2018, 1:10 PM
kadircet added inline comments.Oct 12 2018, 10:33 PM
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).

sammccall marked an inline comment as done.

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.
(Personally this just seems like noise to me, so I'd rather the client omit it, but...)

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).

kadircet accepted this revision.Oct 16 2018, 8:54 AM

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.

This revision is now accepted and ready to land.Oct 16 2018, 8:54 AM
sammccall added inline comments.Oct 16 2018, 9:29 AM
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.

sammccall updated this revision to Diff 169837.Oct 16 2018, 9:30 AM

rebase only

This revision was automatically updated to reflect the committed changes.
clang-tools-extra/trunk/test/clangd/fixits-command.test