Oddities in statically resolved method constraints and method overloading

[RealmPlume]

Case 1

type Test() =
     member __.Equals (_: Test) = true

let inline Equals(a: obj) (b: ^t) =
    match a with
    | :? ^t as x -> (^t: (member Equals: ^t -> bool) (b, x))
    | _-> false

let a: Test = Test()
let b:Test = Test()
//b <- null

printfn "%A" (Equals a b)

I expected to call Test.Equals: Test->unit, (Equals a b) return true
but actually it call Object.Equals: obj->unit, return false

Case 2:

type X =
    static member Method (a: obj) = 1
    static member Method (a: int) = 2
    static member Method (a: int64) = 3


let inline Test< ^t, ^a when ^t: (static member Method: ^a -> int)> (value: ^a) =
    ( ^t: (static member Method: ^a -> int)(value))

let inline Test2< ^t> a = Test<X, ^t> a

printfn "%d" (Test2<int> 0)

I expected return 2, but actually it return 1

[dsyme]

@greatim Thanks for the clean report, I will be looking into this closely

[dsyme]

@greatim Please see #3967 for proposed resolution

[realvictorprm]

In case 2 there's certainly the bug that our type constrains either get lost or are ignored.

[realvictorprm]

@dsyme
@jindraivanek and me noticed that if you change Case 2 to this:

type X =
    static member Method (a: int) = 2
    static member Method (a: int64) = 3


let inline Test< ^t, ^a when ^t: (static member Method: ^a -> int)> (value: ^a) =
    ( ^t: (static member Method: ^a -> int)(value))

let inline Test2< ^t> a = Test<X, ^t> a

printfn "%d" (Test2<int> 0)

Now we get super fancy weird compiler errors:

  let inline Test2< ^t> a = Test<X, ^t> a
  --------------------------^^^^

stdin(9,27): error FS0043: No overloads match for method 'Method'. The available overloads are shown below.
Possible overload: 'static member X.Method : a:int64 -> int'. Type constraint mismatch. The type 
    ''t'    
is not compatible with type
    'int64'    
.
Possible overload: 'static member X.Method : a:int -> int'. Type constraint mismatch. The type 
    ''t'    
is not compatible with type
    'int'    
.

This isn't an oddity @dsyme this is a clear bug.

[realvictorprm]

I do have a fix for this consisting mainly of your code with removing 4 lines. It also would fix Case 1.
Do we want to have a fix for this?

To my understanding the problem lies in that the compiler either

1. stops searching for a correct overload too early
2. applies constrains on the type parameters too late so that object is chosen as solution.

Please note that this behaviour is reproducable with my branch of your fix https://github.com/Microsoft/visualfsharp/pull/5141/files