Implement handling of rename intent

[dibarbet]

The next refactoring intellicode is interested in

[dibarbet]

rename requires us to support multiple document changes. instead of outright removing this, obsoleting until intellicode can react to avoid dual insertion

[dibarbet]

@pgroene you'll need to switch to using this to get the text edits to apply. Should be fairly self explanatory, contains the text changes that should be applied to each URI.

[CyrusNajmabadi]

why URIs instead of DocumentIds?

[dibarbet]

@pgroene to invoke rename, you'll pass the name plus a json like { "newName": "<new name>" }. The prior selection can just be the caret position of any of instances of the symbol.

[dibarbet]

this was mainly for tests. test documents are created as non-rooted paths (e.g. "test1.cs") so we can't use absolute paths. If its non-rooted we just create a relative URI instead.

[CyrusNajmabadi]

why are we using URIs :D

[dibarbet]

@CyrusNajmabadi - you mean in general for exposing the doc changes to intellicode? technically we could use roslyn documents I suppose

@pgroene do you have a preference?

[dibarbet]

confirmed offline intellicode can use documentid. will update this to match

[CyrusNajmabadi]

can we revert this change then?

[dibarbet]

@CyrusNajmabadi if you have a chance could use a review on this for intellicode experimentation

[CyrusNajmabadi]

is this like a json deserialization thing?

[dibarbet]

yup, and the string they pass us is nullable in the API so we have to account for it

[CyrusNajmabadi]

akready checked above.

[dibarbet]

🤦‍♂️

[CyrusNajmabadi]

it's a pity this has to be computed up front. It seems like we want a 'compute + resolve' approach where we determine if the rename is valid, then prose asks the user "do you want to rename?" then it calls back into us for the expensive bit.

renames (esp. on large solutions take a lot of time) so i'm worried this will basically make the feature not work unless you have small solutions.

[dibarbet]

discussed offline - for now this is just for testing to make sure we can reliably detect this and give something valuable. For actual release we will need to consider potentially different UX that allows us to potentially lazily resolve the actual edits, maybe with something like a background work indicator.

Determining if rename can be done is cheap, but actually calculating the edits is really expensive , like 20s expensive on something like roslyn since its basically a FAR operation. This is applicable in general to all our code actions as they can be expensive to compute.

There are some optimizations here we could consider - like for example providing the rename locations only in the current document upfront to intellicode (less expensive) and then only doing the full rename on commit of the action.

This is something we'll need to design and discuss (cc @pgroene)