Witness to trait constraint causes throw of TypeInitializationException in Debug build

[abelbraaksma]

Description

The following code, redacted to closely match this brilliant idea of polyvariadic functions in F# on StackOverflow.com from Gustavo (not sure about his Github name) throws a TypeInitializationException when run as a Debug build.

Repro steps

Here's a solution with the full repro, run in Debug build to see the issue: FSharpBug#865.zip.

Or: copy the following code in an empty project and run with F5 in a Debug build, it will throw the TypeInitializationException.

// From: http://stackoverflow.com/questions/28243963/how-to-write-a-variadic-function-in-f-emulating-a-similar-haskell-solution/28244413#28244413
type T = T with
    static member        ($) (T, _:int    ) = (+)
    static member        ($) (T, _:decimal) = (+)       // required, if only the prev line is here, type inference will constrain too much

[<AutoOpen>]
module TestT =
    let inline sum (i:'a) (x:'a) :'r = (T $ Unchecked.defaultof<'r>) i x

type T with
    static member inline ($) (T, _:'t-> 'rest) = fun (a:'t) -> (+) a >> sum

module TestT2 =
    let x:int = sum 2 3 
    let y:int = sum 2 3 4       // this line throws TypeInitializationException in Debug build

[<EntryPoint>]
let main argv = 
    0

Expected

No exceptions expected.

Actual

Throws TypeInitializationException and debugger shows assembler view:

The type initializer for '<StartupCode$Experiments>.$Program' threw an exception.

The stacktrace is empty, the assembler view is unfortunate (if such exceptions rise I'd kind of expect the actual line to be hit or visible in the stacktrace) . Placing a breakpoint right before let y shows that that's the line that triggers the exception in the startup code.

Severity

Possibly high, because there should not be a difference in executing a debug build vs a release build, and certainly this code should not throw a TypeInitializationException.

Version

Tested with VS2015 (14.0.23107.0) and VS2012. It fails at least in these version combinations:

• FSharp.Core 4.3.0 (4.03.50727.0)
• FSharp.Core 4.3.1 (4.31.30826.0)
• FSharp.Core 4.4 (4.40.23020.0)
• with .NET 4.5, 4.5.1, 4.5.2, 4.6
• with or without RyuJIT enabled

All's tested without Update 1 or 2.

Workarounds

None that I am aware of (though I'd be interested in suggestions).

Other info

I know it is by design that let-bindings are loaded on first use of an assembly, but as seen here this can lead to hard-to-debug errors. Not that late-binding would have helped here, except perhaps for a more interesting stacktrace (I was quite surprised to find the error being raised without anything in the main function and with an empty stacktrace, until it hit me).

Additional info (update)

I noticed that, using Historical Debugging, prior to the TypeInitializationException, a NotSupportedException was thrown. However, the debugger refused to show the disassembly. The NSE was raised on the >> sum part in the code above.

'System.NotSupportedException' in FSharpBug865.exe ("Specified method is not supported.")   

Stacktrace of that exception;

FSharpBug865.exe!op_Dollar@11-4.Invoke(b i = {unknown}, b x = {unknown})
FSharpBug865.exe!<StartupCode$FSharpBug865>.$Program..cctor()
FSharpBug865.exe!Program.main(string[] argv = {unknown})

[gusty]

I didn't notice it at the moment of writing that code, but I already experienced type inference failing to compile and null value runtime exception, both only in Debug mode, in different code fragments, using static constraints and overload resolution which I didn't report because was not easy to find a small repro at the moment. Hopefully this report helps to find the issue.

[dsyme]

Could you please check if the generated code passes peverify.exe?

[abelbraaksma]

For ease of repro (and per the guidelines), here's a sln + fsproj file that illustrates this bug report:
FSharpBug#865.zip

Could you please check if the generated code passes peverify.exe?

@dsyme Both the Debug and Release builds pass peverify without errors:

D:\Projects\FSharpBug#865\FSharpBug865\bin\Debug>peverify FSharpBug865.exe

Microsoft (R) .NET Framework PE Verifier.  Version  4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

All Classes and Methods in FSharpBug865.exe Verified.

[abelbraaksma]

@dsyme I just noticed something else that may help with research: just prior to TypeInitializationException a NotSupportedException is thrown, though I can't make out the precise reason. I have update the OP with this info and a stacktrace.

[abelbraaksma]

@dsyme I found the difference, though I don't understand it.

The compiler creates four generic overloads for $, op_Dollar@11-2 to @11-5. The Invoke method of op_Dollar@11-4 contains the following body (others seem to have some kind of sensible implementation):

.method public strict virtual instance !c 
        Invoke(!b i,
               !b x) cil managed
{
  // Code size       31 (0x1f)
  .maxstack  8
  .language '{AB4F38C9-B6E6-43BA-BE3B-58080B2CCCE3}', '{994B45C4-E6E9-11D2-903F-00C04FA302A1}', '{5A869D0B-6611-11D3-BD2A-0000F80849BD}'
// Source File 'D:\Projects\FSharpBug#865\FSharpBug865\Program.fs' 
  .line 11,11 : 73,76 'D:\\Projects\\FSharpBug#865\\FSharpBug865\\Program.fs'
//000011:     static member inline ($) (T, _:'t-> 'rest) = fun (a:'t) -> (+) a >> sum
  IL_0000:  nop
  IL_0001:  ldc.i4.0
  IL_0002:  brfalse.s  IL_000c
  IL_0004:  ldnull
  IL_0005:  unbox.any  class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<!b,class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<!b,!c>>
  IL_000a:  br.s       IL_0017
  IL_000c:  ldstr      "Dynamic invocation of op_Dollar is not supported"
  IL_0011:  newobj     instance void [mscorlib]System.NotSupportedException::.ctor()
  IL_0016:  throw
  IL_0017:  ldarg.1
  IL_0018:  ldarg.2
  IL_0019:  call       !!0 class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<!b,!b>::InvokeFast<!3>(class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<!0,class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<!1,!!0>>,
                                                                                                        !0,
                                                                                                        !1)
  IL_001e:  ret
} // end of method 'op_Dollar@11-4'::Invoke

Note the NotSupportedException. Also note that the ldstr appears to have no effect (i.e., the exception will not show the message "Dynamic invocation of op_Dollar is not supported").

Then there's the body of TestT.sum<a, r>(a, a): r, which looks like this:

.method public static !!r  sum<a,r>(!!a i,
                                    !!a x) cil managed
{
  .custom instance void [FSharp.Core]Microsoft.FSharp.Core.CompilationArgumentCountsAttribute::.ctor(int32[]) = ( 01 00 02 00 00 00 01 00 00 00 01 00 00 00 00 00 ) 
  // Code size       31 (0x1f)
  .maxstack  8
  .language '{AB4F38C9-B6E6-43BA-BE3B-58080B2CCCE3}', '{994B45C4-E6E9-11D2-903F-00C04FA302A1}', '{5A869D0B-6611-11D3-BD2A-0000F80849BD}'
// Source File 'D:\Projects\FSharpBug#865\FSharpBug865\Program.fs' 
  .line 8,8 : 40,73 'D:\\Projects\\FSharpBug#865\\FSharpBug865\\Program.fs'
//000008:     let inline sum (i:'a) (x:'a) :'r = (T $ Unchecked.defaultof<'r>) i x
  IL_0000:  nop
  IL_0001:  ldc.i4.0
  IL_0002:  brfalse.s  IL_000c
  IL_0004:  ldnull
  IL_0005:  unbox.any  class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<!!a,class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<!!a,!!r>>
  IL_000a:  br.s       IL_0017
  IL_000c:  ldstr      "Dynamic invocation of op_Dollar is not supported"
  IL_0011:  newobj     instance void [mscorlib]System.NotSupportedException::.ctor()
  IL_0016:  throw
  IL_0017:  ldarg.0
  IL_0018:  ldarg.1
  IL_0019:  call       !!0 class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<!!0,!!0>::InvokeFast<!!1>(class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<!0,class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<!1,!!0>>,
                                                                                                           !0,
                                                                                                           !1)
  IL_001e:  ret
} // end of method TestT::sum

Again, notice the unconditional throwing of the NotSupportedException and the ldstr which has no effect.

This latter code (the sum version) appears to be called when using the Debug build. When using the Release build, this code can also be found, but is never called.

This raises the following questions:

• Why are methods created that throw NotSupportedException?
• Even if these methods have a certain use, why does the Debug build call the wrong method?
• Can these failing methods with the NSE also be created in other cases (operator overloads, "normal" methods/functions?)
• Does a workaround exist to prevent this code from being created/called?

[dsyme]

Thanks for the info. We'll look into it. In the meantime avoid the coding pattern for now.

[abelbraaksma]

Also, both versions create a y@15 type with an Invoke(int, int) method. At some point during type initialization, the following (reflected, C#) code is called, which is from that type:

Debug:

public override FSharpFunc<int, int> Invoke(int i, int x)
{
    return FSharpFunc<int, int>.InvokeFast<FSharpFunc<int, int>>(Program.T.op_Dollar<int, int, int, int, int>(Program.T.get_T(), null), i, x);
}

Release:

public override FSharpFunc<int, int> Invoke(int i, int x)
{
    return FSharpFunc<int, int>.InvokeFast<FSharpFunc<int, int>>(new Program.TestT2.y@15-1(), i, x);
}

The Debug version above calls op_Dollar<int, int, int, int, int> which after some detours calls the method op_Dollar<t, a, b, c>.Invoke(), which throws the NSE.

The Release version never gets there.

[abelbraaksma]

@dsyme, thanks. Indeed, I couldn't use the pattern as of yet because of this, even if I wanted to...

EDIT: one final thing, for now, I just tested it with other operators than $ in case it is treated specially, (reserved for future use or something), but it has the same effect, here are the throwing lines in ILASM (using ^^ instead of $):

IL_000c:  ldstr      "Dynamic invocation of op_HatHat is not supported"
IL_0011:  newobj     instance void [mscorlib]System.NotSupportedException::.ctor()
IL_0016:  throw