Clarify responses to rename request.

[doriath]

The main goal is to clarify how the null value should be used.
Currently it is not clear in what cases server is allowed to return it,
and how clients should interpret it. #566

[doriath]

Why?

First, let me explain why I would like to add this clarification here. ~2 months ago I was playing with RLS (Rust language server) and vim-lsp (client for vim) and I found that rename was not a great user experience.

Here is why:

• RLS returns null when rename did not succeed (for any reason). This also included cases like the code doesn't compile, so rename cannot be performed
• vim-lsp does nothing when null is returned

This means that when I tried to rename something and it failed, I had no message telling me that something failed. From the client (vim-lsp) perspective, it is not clear how to interpret the null response - was there just nothing to do, or was there some error and rename was not performed.

Alternative

In my Pull Request, I went with the proposal of treating null as "nothing has to be done". The alternative approach could be to use it as generic "rename failed" indication.

If this one is preferred, I would propose:

• clarify that clients can treat this value as "can't perform rename at this position"
• generally discourage server implementations from returning null, in favor of returning clear error message. For example: the position is not at any symbol (e.g. space or brackets), current symbol does not support renames or the code doesn't compile.

After writing this explanation, I am slightly starting to lean toward the alternative proposal, but I will wait for the feedback first.

[KamasamaK]

Should be "the same way as".

[KamasamaK]

Use either "in case" or "when", not both.

[dbaeumer]

@doriath there is now a PrepareRenameRequest that can be sent from the client to the server to test if a position can be renamed. So I would like to only clarify the spec that null should be treated the same way as an empty edit. I would not bind this to newName is the same than oldName.

Can you adjust the PR accordingly ?

[doriath]

dbaeumer@ I agree that there is now PrepareRenameRequest that mostly solves this issue, but even if I control one side (client or server), the other side can still opt-out. That means that sometimes I will need to use just the RenameRequest and I want to make sure I can handle it properly on both sides.

Just so that I understand, is there another case where null / empty edit could be returned, other than newName equal oldName?

[dbaeumer]

@doriath there is a difference between a rename request at an invalid position. In this case a server should return an error. If it did nothing (for whatever reason) then it should return null or an [] array.

[dbaeumer]

Merged by hand into 3.17.