Build fails with Error FS2014 when a signature file is used with IWSAMs

[jrharnden]

This appears to be directly related to #15919. The fix identified by @vzarytovskii and implemented by @gusty works for the scenario below when there is no signature file. When a signature file is added it still triggers the error. The types do not even need to be in the signature file to trigger the error.

Error:

A problem occurred writing the binary 'obj\Debug\net7.0\refint\Foo.dll': Error in pass3 for type Foo, error: Error in pass3 for type CompilerGoesBoom1, error: Error in GetMethodRefAsMethodDefIdx for mref = ("Foo.IHasStaticAbstractBase<'a>.Boom", "CompilerGoesBoom1"), error: MethodDefNotFound

Scenario identified by @En3Tho:

type IHasStaticAbstractBase<'a> =
    static abstract Boom: unit -> 'a

type IHasStaticAbstractChild<'a> =
    inherit IHasStaticAbstractBase<'a>

type CompilerGoesBoom<'a>() =
    interface IHasStaticAbstractChild<'a> with // this goes boom because inheritance is involved
        static member Boom() = Unchecked.defaultof<'a>

type CompilerDoesNotGoBoom<'a>() =
    interface IHasStaticAbstractBase<'a> with // this does not go boom, direct base interface
        static member Boom() = Unchecked.defaultof<'a>

[vzarytovskii]

Hm. Interesting. @jrharnden is this on the main?

[jrharnden]

I backported the changes to fsharp-release-dev17.7 prior to the .net 8 release. I can check on main real quick.

[vzarytovskii]

I have no idea currently why it's failing, but might be some weird case of us merging empty signature and implementation and not doing fixup or something.

[jrharnden]

It looks like the same issue occurs on the main branch. To clarify, triggering the bug doesn't require the signature to be empty, just for a signature file to exist. It still fails with the signature below.

type IHasStaticAbstractBase<'a> =
    static abstract Boom: unit -> 'a

[<Interface>]
type IHasStaticAbstractChild<'a> =
    inherit IHasStaticAbstractBase<'a>

[<Class>]
type CompilerGoesBoom<'a> =
    interface IHasStaticAbstractChild<'a>

[<Class>]
type CompilerDoesNotGoBoom<'a> =
    interface IHasStaticAbstractBase<'a>

[vzarytovskii]

It looks like the same issue occurs on the main branch. To clarify, triggering the bug doesn't require the signature to be empty, just for a signature file to exist. It still fails with the signature below.

type IHasStaticAbstractBase<'a> =

    static abstract Boom: unit -> 'a



[<Interface>]

type IHasStaticAbstractChild<'a> =

    inherit IHasStaticAbstractBase<'a>



[<Class>]

type CompilerGoesBoom<'a> =

    interface IHasStaticAbstractChild<'a>



[<Class>]

type CompilerDoesNotGoBoom<'a> =

    interface IHasStaticAbstractBase<'a>

Yeah, I didn't mean to emphasize on empty signature, just signature. We probably do something different when we merge those.

Will need to spend some time to figure it out.

[vzarytovskii]

@jrharnden I can't seem to reproduce it:

> cat repro.fs

namespace Foobar
type IHasStaticAbstractBase<'a> =
    static abstract Boom: unit -> 'a

type IHasStaticAbstractChild<'a> =
    inherit IHasStaticAbstractBase<'a>

type CompilerGoesBoom<'a>() =
    interface IHasStaticAbstractChild<'a> with
        static member Boom() = Unchecked.defaultof<'a>

> cat repro.fsi

namespace Foobar

> cat repro.rsp

--target:library
--targetprofile:netstandard
--simpleresolution
repro.fsi
repro.fs

> dotnet artifacts/bin/fsc/Debug/net8.0/fsc.dll @repro.rsp
Microsoft (R) F# Compiler version 12.8.0.0 for F# 8.0
Copyright (c) Microsoft Corporation. All Rights Reserved.

/Users/u/code/fsharp/repro.fs(3,5): warning FS3535: Declaring "interfaces with static abstract methods" is an advanced feature. See https://aka.ms/fsharp-iwsams for guidance. You can disable this warning by using '#nowarn "3535"' or '--nowarn:3535'.

> file repro.dll
repro.dll: PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows

[vzarytovskii]

Same with the following signature file:

type IHasStaticAbstractBase<'a> =
    static abstract Boom: unit -> 'a

[<Interface>]
type IHasStaticAbstractChild<'a> =
    inherit IHasStaticAbstractBase<'a>

[<Class>]
type CompilerGoesBoom<'a> =
    interface IHasStaticAbstractChild<'a>

[vzarytovskii]

> git rev-parse HEAD

2a25184293e39a635217670652b00680de04472a

[jrharnden]

Foobar.zip
Sorry. I've been running it directly from visual studio. I've attached a minimal repro setup for this method. I need to go do family stuff for now, but I can try to get a command line repro later tonight. Excluding the signature file from the solution should make the bug go away. Compiler is copied directly from artifacts\bin\fsc\Release\net8.0 on the same commit you as you have above.

[vzarytovskii]

Foobar.zip

Sorry. I've been running it directly from visual studio. I've attached a minimal repro setup for this method. I need to go do family stuff for now, but I can try to get a command line repro later tonight. Excluding the signature file from the solution should make the bug go away. Compiler is copied directly from artifacts\bin\fsc\Release\net8.0 on the same commit you as you have above.

In vs meaning, you see it in ide, or build it in ide and see output? Also, where do you replace the compiler?

[jrharnden]

I open that attached project in the latest Visual Studio 2022 community edition and build it using f5. The copy of the compiler mentioned is in the top-level tools directory. It is chosen using the property group below in the project file. The error should show up in the error window within visual studio once it builds. The build output text leads me to believe that the correct compiler is being used and should show the compiler options chosen as well.

  <PropertyGroup>
    <FSharp_Shim_Present>false</FSharp_Shim_Present>
    <FscToolPath>$(SolutionDir)tools</FscToolPath>
    <FscToolExe>fsc.exe</FscToolExe>
    <DotnetFscCompilerPath></DotnetFscCompilerPath>
    <FSharpPreferNetFrameworkTools>False</FSharpPreferNetFrameworkTools>
    <FSharpPrefer64BitTools>True</FSharpPrefer64BitTools>
  </PropertyGroup>

[jrharnden]

It looks like the problem is related to reference assemblies which I guess are enabled by default in Visual Studio. I can reproduce it using the same commands you were using and the rsp file below. I can also successfully build the solution in visual studio now if I set the ProduceReferenceAssembly property to false in the project config file. It looks like you are aware of the issue already #15919 (comment) ? If so, sorry for the wild goose chase. I really appreciate your help though!

--target:library
--targetprofile:netstandard
--simpleresolution
--refout:RefRepro.dll
repro.fsi
repro.fs