The following code prevents the compiler from terminating

[LukaHorvat]

I reported this to fsharp and it was suggested I should report it here as well.

Description:
The idea was to make a function format that can return any function which's type passes a static check. The functions that are valid take parameters (arbitrarily many) of type string or int and produce either a unit or an int.
Including the checker function in another function would make sure that the type parameter is a valid function type, which would then be constructed unsafely via reflection or similar and then finally casted to the appropriate target type.

Unfortunately, this code causes the compiler to hang indefinitely (or as far as my patience extended).
This might not be a bug if it's a design decision to allow non-termination, but I'd find that strange considering my code consists only of valid language constructs.

Repro Steps:
Compile this code

type Switcher = Switcher

let inline checker< ^s, ^r when (^s or ^r) : (static member pass : ^r -> unit)> (s : ^s) (r : ^r) = ()

let inline format () : ^r =
    checker Switcher Unchecked.defaultof< ^r>
    () :> obj :?> ^r

type Switcher with
    static member inline pass(_ : string -> ^r) =
        checker Switcher Unchecked.defaultof< ^r>
    static member inline pass(_ : int -> ^r) =
        checker Switcher Unchecked.defaultof< ^r>
    static member inline pass(_ : unit) = ()
    static member inline pass(_ : int) = ()

[<EntryPoint>]
let main argv = 
    let res : unit = format () "text" 5 "more text" ()
    printfn "%A" res
    Console.ReadKey()
    0 // return an integer exit code

Severity: It's pretty bad that the compiler fails to terminate, but it's a fairly obscure use case.

Version: Visual Studio 2015 Preview, my project targets .NET Framework 4.5.3 and the runtime is F# 4.0 (FSharp.Core, 4.4.0.0)

[latkin]

I can repro. Pasting the code into the editor causes VS to spin CPU indefinitely, too.

[rojepp]

I can repro in Xamarin Studio on OSX, so it's not a F# 4.0 issue.

[dsyme]

I've taken a look at this with a view to whether to attempt a fix (or restriction) for F# 4.0. However, it's hard - it involves error paths during very nested overload resolution.

In any case, given where we are with the F# 4.0 RTM milestone, I haven't been able to determine a non-destabilizing fix that's appropriate at this stage. I believe this will need to be fixed at a later stage. The fix could be along the lines of a language restriction that require more complete signatures to be given in some situations,

In this example, it's not clear if progress is being made (though slowly, which would still be an issue) or if there is actually a proper loop. @forki also took a look and may have more to share.

[forki]

From my limited understanding it didn't made progress. Instead it circled
between two states.
On May 9, 2015 2:29 PM, "Don Syme" notifications@github.com wrote:

I've taken a look at this with a view to whether to attempt a fix (or
restriction) for F# 4.0. However, it's hard - it involves error paths
during very nested overload resolution.

In any case, given where we are with the F# 4.0 RTM milestone, I haven't
been able to determine a non-destabilizing fix that's appropriate at this
stage. I believe this will need to be fixed at a later stage. The fix could
be along the lines of a language restriction that require more complete
signatures to be given in some situations,

In this example, it's not clear if progress is being made (though slowly,
which would still be an issue) or if there is actually a proper loop.
@forki https://github.com/forki also took a look and may have more to
share.

—
Reply to this email directly or view it on GitHub
#351 (comment)
.

[dsyme]

See also #395, which I'm considering a duplicate of this as I suspect the underlying causes to be the same.

[dsyme]

Closing as a duplicate of #343 (it seems the compiler is making progress, just very slowly)

[forki]

with @gmpl's PR 1530 applied this immediatly gives:

Is that expected? I tried to put that in #1550

[gusty]

After analyzing and working with the Constraint Solver I'm not surprised that some samples (like this) never ends.
But after the fix I'm proposing they should.
Now, whether they end successfully or with an error is a different thing.
I need to study more this repro, but in principle I would say that if the code in the repro makes sense it should compile and if it don't compile then we're facing another compiler bug, similar to the ones I reported and they should be fixed in a separated pull request.

[forki]

@gmpl one thing is for sure: giving a error message immediately is better than compiler going into quasi infinite loop. So from my point of view your pr is a win for this case here.