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

@vasily-kirichenko

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.

Symbols for operators except for >>= are picked up. For >>=, there is nothing - no QuickInfo, no document highlight, etc.
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.

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

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.

@isaacabraham

@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.

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

It was for record field.

@isaacabraham

@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.

@abelbraaksma

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?

#3493 is tracking the rename/record label issue

Find all refs on ThisIsAProperty works in 15.4:

Rename does not work.

@vzarytovskii

@vzarytovskii, you linked that other issue recently, but I think this is resolved now. Here's an exercise in obfuscated code in VSCode:

And here's Visual Studio 2022, latest:

Also, hovering over any of these (left-angle or right-angle) shows the tooltip, in which you can click to "go to definition". And typing the dot at the end does NOT show a dropdown list of functions anymore (which is good).

It must have been fixed quite recently, as I'm quite certain that I kept seeing this issue until not so long ago.

@cartermp, you created this issue 7 years ago, do you agree to close as resolved? While the only coloring issue is still with (*), the style guide requires to write it as ( * ) in which case all's good anyway. Not really worth spending too much time on.

@abelbraaksma

@abelbraaksma Things like this still reproduce for me in both VS and Ionide.

let (..>=) = (>=)
let (>..=>) = (>=)
let (>>>>) = (>)
let (.>>>>) = (>)
let (>>>>.) = (>)
let (<<<<) = (<)
let (.<<<<) = (<)
let (<<<<.) = (<)

let _ = 2 ..>= 2
let _ = 2 >..=> 2
let _ = 2 >>>> 2
let _ = 2 .>>>> 2
let _ = 2 >>>>. 2
let _ = 2 <<<< 2
let _ = 2 .<<<< 2
let _ = 2 <<<<. 2

op_names_tooltips.mp4

It seems there are likely multiple different bugs involved here, since the coloring behavior does not correlate exactly with the tooltip (and go-to-definition, rename, etc.) behavior.

@brianrourkeboll

@brianrourkeboll do I see this correctly: only when there's a leading dot and a following angle bracket, that there's still a coloring issue and/or tooltip issue?

It looks to me that anything else is good now, right?

only when there's a leading dot and a following angle bracket, that there's still a coloring issue and/or tooltip issue?

The color is different when there is a leading > (with no leading .s).

It looks to me that anything else is good now, right?

I am not sure. I actually started looking at this a while ago, and I feel like there were still some more scenarios that could lead to these inconsistencies, but I don't remember.

I just played around for another minute now, and it seems that more than one trailing . also breaks things, regardless of what the first character is:

let (+..) = (+)

let _ = 2 +.. 2

There may be more such combinations.

Edit: :> and :?> also don't get tooltips. Should they?

Thanks. The color difference is very subtle in your video (bold vs not bold, it seems), I think that's what you mean?

Let's leave the issue open for the remaining cases.

The color difference is very subtle in your video (bold vs not bold, it seems), I think that's what you mean?

Yes, it's much more noticeable in other themes:

🤖 This is an automated response from Repo Assist.

This is FSharp.Compiler.Service behavior and is reproducible on Linux, so I removed the AI-thinks-windows-only label.

I tested the latest repro from the comments against commit 4831b381ee941f8bb03a19332c671ac86b9e82c3 (2026-09-25, four days old) using the freshly built FSI/FCS artifacts:

Microsoft (R) F# Interactive version 15.2.200.0 for F# 11.2
FSharp.Core: 11.0.0.0
.NET: .NET 11.0.0-rc.1.26420.103
OS: Linux

For ..>=, >..=>, >>>>, .>>>>, >>>>., <<<<, .<<<<, and <<<<., GetAllUsesOfAllSymbolsInFile returns both declaration and use, semantic classification reports Operator, GetToolTip returns the custom operator signature, and GetDeclarationLocation lands on the declaration. Those cases are fixed.

The broader trailing-dot case from the latest human comment still fails:

let (+..) = (+)
let _ = 2 +.. 2

FCS finds both symbol uses and classifies +.. as Operator, but GetToolTip(2, 13, "let _ = 2 +.. 2", [ "+.." ], FSharpTokenTag.Identifier) returns ToolTipText [], and GetDeclarationLocation returns DeclNotFound (Unknown ""). The issue therefore remains open, narrowed to tooltip/navigation parsing for this operator shape.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

southcentralus0.in.applicationinsights.azure.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "southcentralus0.in.applicationinsights.azure.com"

See Network Configuration for more information.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

Add this agentic workflows to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@7c7feb61a52b662eb2089aa2945588b7a200d404

Navigation Menu

Repository navigation

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

Current status

Update 2

Update 1

Old Issue

34 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Current status

Update 2

Update 1

Old Issue

Activity

cartermp commented on Aug 18, 2017

isaacabraham commented on Aug 22, 2017

cartermp commented on Aug 22, 2017

cartermp commented on Aug 22, 2017

isaacabraham commented on Aug 22, 2017

abelbraaksma commented on Aug 22, 2017

cartermp commented on Aug 23, 2017

cartermp commented on Aug 23, 2017

vasily-kirichenko commented on Oct 15, 2017

34 remaining items

abelbraaksma commented on May 6, 2024

brianrourkeboll commented on May 6, 2024

abelbraaksma commented on May 6, 2024

brianrourkeboll commented on May 6, 2024

abelbraaksma commented on May 6, 2024

brianrourkeboll commented on May 6, 2024

github-actions commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions