Closed bstaletic closed 3 weeks ago
Attention: Patch coverage is 94.28571%
with 2 lines
in your changes missing coverage. Please review.
Project coverage is 95.90%. Comparing base (
6f1f4f8
) to head (a5f4086
). Report is 4 commits behind head on master.
I'm finally happy with this pull request. Codecov says that I should have covered the changes better, but the overall coverage is up.
Thanks for sending a PR!
So... We advertise that we can handle CodeActions that are either missing an edit or a command (or both). The server chooses whether it supports either of the two. If it does, it advertises itself as a "code action resolve provider".
For servers that are code action resolve providers:
For servers that are not code action resolve providers, the steps are the same, but we skip the codeAction/resolve route.
One thing missing is properly defined handling of fixit resolutions that yield multiple fixits. That can happen in a few ways:
The first two above don't seem to be used by any server ever. The LSP specs nudges servers away from doing that, but no promises. We are still not supporting any scenario where resolving a single fixit results in more than one fixit.
Another scenario that does not seem to happen:
In practice, such code actions resolve to a CodeAction containing an edit.
As for the ycmd<->client side of things... it's a bit ugly on the ycmd side, but we're completely preserving the API, so clients do not need to change a thing.
Previously, clients got
{ 'fixits': [ { 'command': LSPCommand ... } ] }
for unresolved fixits. However, we have not given any guarantees about the value of'command'
. We have only said that it should be returned to ycmd for the purposes of/resolve_fixit
. With this pull request, we need to pass the entire CodeAction, but we're still putting it in thecommand
key.This change is![Reviewable](https://reviewable.io/review_button.svg)