You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Provide actual name ranges for FSharpSymbolUse #3920
@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.
@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).
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
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).
Activity
dsyme commentedon Nov 10, 2017
@auduchinok I suppose providing just the range
FromStringwould 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 commentedon Nov 10, 2017
@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 commentedon Nov 10, 2017
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 commentedon Nov 10, 2017
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 commentedon Nov 10, 2017
@vasily-kirichenko Thanks for checking!
vasily-kirichenko commentedon Nov 10, 2017
Implemented in #3922. I think there will be a storm of failing tests :)
vasily-kirichenko commentedon Nov 14, 2017
@auduchinok
auduchinok commentedon Nov 14, 2017
@vasily-kirichenko This is great!
Looking at how
LexBufferis highlighted it looks like<_>is still in its range.vasily-kirichenko commentedon Nov 14, 2017
Yes.
dsyme commentedon Apr 5, 2022
There is a duplicate of this error where "<_>" is still included. I will close this.
Narrow name-resolution sink range to terminal identifier (#3920)
Narrow name-resolution sink range to terminal identifier (#3920)
Narrow overload-error and symbol-use ranges to terminal identifier (#…
Scope down to Method-only: revert sink narrowing and workaround
Narrow overload-error and symbol-use ranges to terminal identifier (#…
[feature/net11-scouting] Update dependencies from dotnet/arcade (#19874)
[feature/net11-scouting] Update dependencies from dotnet/arcade (#19910)