Operators starting with '>' don't get IDE features

[cartermp]

Current status

It seems that symbols for operators are sometimes picked up for document highlight and inline rename, but it's inconsistent. Given the following code in a .NET Core project:

module Operators =
    let (>>=) a f = Result.bind f a
    let (<*>) x f = f x
    let (<!>) = Result.map
    let (<+>) x f = f x
    let (<?>) x f = f x

open Operators

[<EntryPoint>]
let main argv =
    (float <!> (Ok 12)) |> ignore

    printfn "Hello World from F#!"
    0 // return an integer exit code

There three notable issues. Some of these are driven by the same root cause as #3873.

1. Symbols for operators except for >>= are picked up. For >>=, there is nothing - no QuickInfo, no document highlight, etc.
2. When you try to rename <!> at the call site, it will escape the symbol with double backticks.

Note that colorization of >>= and any operator that starts with > is similarly affected, as per #10272

Update 2

Modules are now found at the open site by Inline Rename and Find all References due to #3803, thanks @vasily-kirichenko

Update 1

Using 15.4.1, and given the following code:

module Foo =
    let (>.>) x f = f x

open Foo

[<EntryPoint>]
let main argv =
    12. >.> sqrt |> ignore
    0 // return an integer exit code

Click on Foo at the declaration site:

Epected --> The Foo at open Foo is highlighted
Actual --> It's not.

Notice that Find Refs and Inline Rename also fail to pick up the symbol.

Click on >.> anywhere it's used.

Expected --> Highlights the operator everywhere it exists
Actual --> No highlight

Find Refs and Inline Rename also do not pick up this symbol.

Old Issue

VS 2017 15.3 + 8/16/2017 nightly build.

Run Find all References or Rename on ThisIsAProperty.

// Learn more about F# at http://fsharp.org
// See the 'F# Tutorial' project for more help.

open TestCS

type C() =
    member val ThisIsAProperty = 12 with get, set

[<EntryPoint>]
let main argv = 
    let c = C()
    c.ThisIsAProperty <- 0
    0 // return an integer exit code

I don't think that this the same as #3033, because rename and FAR work for the class definition itself.

The above also fails on modules and customer operators.

[cartermp]

Dunno if this is relevant, but in debugging, I noticed that this line gets hit four times on ThisIsAProperty has a match, when document highlight hits it twice. I'll probably debug this tomorrow when I'm not dead tired

[isaacabraham]

I'm not sure if this is the same issue. I've just upgraded to latest nightly and VS2017 etc.. In a standalone script file, if I try to F2 rename, the dialog pops up etc. but as soon as I start typing, the refactoring disappears and the original symbol is untouched.

[cartermp]

@isaacabraham Can you be specific about which constructs this fails on? This works fine in scripts for functions, F# types, F# class names, etc. But fails for members, modules, and operators.

[cartermp]

In a hive of VS, Find all References works for properties, but outside of that hive, it doesn't. Rename fails, though.

[isaacabraham]

It was for record field.

[abelbraaksma]

@isaacabraham, @cartermp, I just tried to repro Isaac's findings (also VS2017 15.3.1.0 P1, nightly of yesterday) and for a record field it pops up with the "apply where" box and I can start typing. However, after hitting the apply-button, some fields are renamed and some aren't.

It looks like for record types it only replaced anything in a full record constructor, not references with dot-notation nor patterns. I'll try to create a small repro (unless already known).

• syntax foo.Bar, where Bar is a record field, changing Bar's definition with Rename, this is not updated
• pattern match syntax | DUFieldName ({ Bar = "test" } as bar) ->// do something is also not renamed (the Bar here, I mean)

Screenshot is just after I changed ImplicitContext to ImplicitContext2, you can see that the main record definition was changed, but right below that where I use it, it did not update. In all it replaced 25 items across multiple projects, missing 11 occurrences.

Summary: the reported bug here also, at least in part, applies to record fields. But I have never seen this feature successful in its fullness so I (unfortunately) stopped using it, so I am uncertain I am reporting something new here.

[cartermp]

Thanks @abelbraaksma, that is also what I see. I'll open a separate issue there.

@isaacabraham is this similar to what you saw as well?

[cartermp]

#3493 is tracking the rename/record label issue