Tooltip shows wrong name resolution on uncallable static member due to name collision

[smoothdeveloper]

module Dom =
  
  type WindowDelimiter =
    | WindowDelimiter of int
    static member FromCs (a: obj) = WindowDelimiter 1
  
  type Tree =
    | WindowDelimiter of WindowDelimiter
    static member FromCs (a: obj) = WindowDelimiter(WindowDelimiter.WindowDelimiter(1))

let a = Dom.WindowDelimiter.FromCs null

Expected behavior

The last line should be OK, even the tooling shows the method in auto-complete, the signature is on the type tooltip, and the member definition highlights when the carret is on the invocation.

Actual behavior

The field , constructor or member 'FromCs' is not defined

Known workarounds

@gusty pointed that SRTP trait call enables calling the member.

let inline fromCs< ^t when  ^t : (static member FromCs : obj ->  ^t)> (x:obj) =
    (^t : (static member FromCs : obj -> 't) (x) )

let a = fromCs<Dom.WindowDelimiter> null

Another work around involve putting RequireQualifiedAccess which is not always possible / wanted.

Related information

Visual Studio 16.5.2

#6805 (comment) => a case where SRTP is useful to work around a compiler limitation.

[charlesroddie]

Simpler reproduction:

module Dom =
    type WindowDelimiter =
        static member FromCs = ()
    type Tree =
        | WindowDelimiter
let a = Dom.WindowDelimiter.FromCs

[cartermp]

This feels like a bug on two fronts:

• FCS is not giving you the correct "view" of the world that compilation does
• The code should probably just compile

@charlesroddie Yours looks slightly different. Since Dom.WindowDelimiter could refer to either construct, the compiler picks the last one that it saw. So in this case it's binding to something that doesn't define FromCs. Annoying, but consistent with shadowing and other "pick the last one we saw" behavior elsewhere.

[charlesroddie]

Since Dom.WindowDelimiter could refer to either construct, the compiler picks the last one that it saw.

Doesn't the fact that my code give the same behaviour show that its the same issue? It eliminates various things that could be causing the issue (multiple potential conflicts in the use of the name WindowDelimiter, and the existence of Tree.FromCs) and shows that they didn't affect the result, leaving you with the issue you identified.

I'm happy to agree with you that my reduction shouldn't compile for this reason, and that the fix should be to adjust intellisense rather than compilation. But that should apply equally to the code in the OP.

[dsyme]

This is currently by design, and an RFC will be needed to change things, so I'm tracking this with this language suggestion fsharp/fslang-suggestions#907

Essentially in Dom.WindowDelimiter the union case is always preferred, and the last union case among many of the same name.

The type should be used to qualify the name in these cases, with or without RequireQUalifiedAccess

The fact that the IDE is showing the other resolution is a bug