FS0192 "destRefTupleTy: not a reference tuple type"

[bent-rasmussen]

Discriminated union with type extension triggers strange error message without syntactic context (no file name or usable line number) nor helpful information about what the issue actually is. The error message looks like an internal F# compiler error message.

Repro steps

Steps required to reproduce the problem:

1. Updated Visual Studio to: Microsoft Visual Studio Professional 2019 Version 16.7.0.
2. Create a new F# .NET Core 3.1 project.
3. Create one file as such:

namespace Foobar

type Identifier =
    | Id of string

and Expression =
    | Identifier of Identifier
    | BinaryOp of Expression * Expression

4. Create another successive file as such:

module Foobar.Extensions

type Expression with

    member this.Foobar2 : unit =
        match this with
        | Identifier _ ->
            ()
        | BinaryOp (_, e2) ->
            e2.Foobar2

5. Compile.

FS0192_destRefTupleTy_not_a_reference_tuple_type.zip

Expected behavior

Expected more meaningful error message or actionable information about what to do or what not to do.

Actual behavior

Somewhat esoteric error message.

I should perhaps note that Visual Studio crashed twice while trimming code to create a minimum repro. The crash was triggered by a compile of the project. Not able to recreate that anymore though.

Known workarounds

• Defining the Foobar2 method directly on the Expression type instead of using a type extension.
• Downgrade Visual Studio

Related information

• Windows Version 10.0.19041 Build 19041
• .NET Core 3.1.
• Microsoft Visual Studio Professional 2019 Version 16.7.0

[abelbraaksma]

Related: #9 (fixed), and #250 (the fix) and #9702, #4825, #6528, #9296 (all related, same error, other cause) and a bunch of others. @cartermp, if I search for that (internal) error, there are quite some reports. Maybe we should prioritize them? I'm not quite sure what causes this, or I could start working on it myself.

Edit: it appears that some may have been fixed, but that issues have remained open.

[cartermp]

Pretty much all of these reports are distinct from one another.

This is another such case 😄

[hyazinthh]

This seems to only happen if the extension method is recursive. An easy workaround is to define a recursive function outside of the extension instead. E.g.

let rec doit (e : Expression) =
    match e with
    | Identifier _ ->
        ()
    | BinaryOp (_, e2) ->
        doit e2

type Expression with

    member this.Foobar2 : unit =
        doit this

[bent-rasmussen]

This seems to only happen if the extension method is recursive. An easy workaround is to define a recursive function outside of the extension instead. E.g.

True, it's an easy workaround if you know where the affected code is; however, error reporting gives no clue, and there can be many recursive type extensions in a codebase. If there is some sort of internal compiler service error, then it may be worth looking into whether it is still possible to capture and report file context.

[dsyme]

Smaller repro:

type Expression =
    | BinaryOp of Expression * Expression


module Extensions =

    type Expression with

        member this.Foobar2 : unit =
            match this with
            | BinaryOp (_, e2) ->
                e2.Foobar2

[Twinside]

Hello,

Is this fix available in Visual Studio 19.7.3? It's not clear from the release notes

[cartermp]

This fix will be in the VS 16.8 release.

[christian-clausen]

This fix will be in the VS 16.8 release.

I just tested @dsyme's smaller repro on VS 16.8.0 Preview 3.0 and still got the "destRefTupleTy: not a reference tuple type" error. Will the fix make it to the next preview?

[cartermp]

Not sure. Bits flow into previews when they flow in. But it will be in the release.

[chaami]

Hi,
Is there an easy way to reference a compiler that doesn't suffer from this bug until 16.8 is out the doors ?
Or we are left with reverting to a 16.6.x version of Visual Studio ?
Thanks in advance.

[cartermp]

@chaami if you're using the .NET SDK, the latest RC has all fixes that will be in the VS 16.8 release. Unfortunately, .NET and VS have orthogonal ship schedules so there isn't much coherence between the two on what gets what aside from the final release. That said, later this month there should be another preview that likely has the fix.

[chaami]

Hi @cartermp ,
Thanks for the information.
I have installed the 5.0.100-rc.2.20479.15 .NET SDK but the build is still failing.
Is there anything else that needs to be done besides installing ?
I am using the Community Edition on my current host and would like to avoid waiting / installing a pro version until this is fixed...
Oddly I just couldn't find a way to install an older VS Community Edition...

[cartermp]

Using the supplied repro this no longer reproduces neither from the command line nor from an internal build of VS that represents something that has yet to ship. SKU of VS shouldn't matter for this. Do you have a repro you can share?

[chaami]

Using the supplied zip fails on Visual Studio Community 16.7.6 but succeeds through the command line (dotnet build).
So I guess switching the TargetFramework is an available workaround as well ?
Thanks for your help !

[cartermp]

@chaami I would expect it to fail in 16.7, yes, and succeed with the latest preview of the .NET SDK. Switching TFM shouldn't have anything to do with this issue, it was a compiler bug that was shipped in the latest .NET 5 RC SDK, and will be available in the VS 16.8 release.