Provide actual name ranges for FSharpSymbolUse

[auduchinok]

Consider a use of FromString below:

let lexbuf = Lexing.LexBuffer<_>.FromString(str)
//           |----------------------------|
// current range is bigger than actual name usage

We could keep start pos of symbol use as well.

[dsyme]

@auduchinok I suppose providing just the range FromString would be simpler and provide for overall accuracy. I don't really know why we provided the long names historically. Do you have any use for them?

My guess is that a fair bit of client FCS code is sensitive to this however.

[auduchinok]

@dsyme No, there's no uses of the full resolved ranges in our code, we trim them.
Talking about client code I've seen (and as we do), there're usually methods that trim these ranges and look error-prone (e.g. looking for dot separator that may be a part of operator).

[dsyme]

Talking about client code I've seen, there're usually methods that trim these ranges and look error-prone (e.g. looking for dot separator that may be a part of operator).

Yeah, I've seen that code too.

I suppose we can do a major version upgrade and put out some info to major consumers that the ranges have changed

[vasily-kirichenko]

I confirm that we don’t rely on long range and trimm them. If we need full long ident, we use QuickParse. I think we should add LongIdent into FSharpSymbolUse (however, we cannot remove QP entirely because we need to parse partially typed symbols in complition).

[dsyme]

@vasily-kirichenko Thanks for checking!

[vasily-kirichenko]

Implemented in #3922. I think there will be a storm of failing tests :)

[vasily-kirichenko]

@auduchinok

[auduchinok]

@vasily-kirichenko This is great!
Looking at how LexBuffer is highlighted it looks like <_> is still in its range.

[vasily-kirichenko]

Yes.

[dsyme]

There is a duplicate of this error where "<_>" is still included. I will close this.