Compile error: "primDestForallTy: not a forall type" #6528

joakimsjo · 2019-04-13T21:57:16Z

On dotnet build or dotnet run yarn-watch compiler fails with an internal error.

Repro steps

Clone my repository from here
Run dotnet build or dotnet run yarn-watch inside "src" folder.

Expected behavior

Compilation succede.

Actual behavior

Compilation fails with following error:

Microsoft (R) Build Engine version 15.9.20+g88f5fadfbe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 24.31 ms for /Users/joakimsjohaug/Projects/fsharp/nobina/app/src/app.fsproj.
  Restore completed in 48.86 ms for /Users/joakimsjohaug/Projects/fsharp/nobina/app/src/app.fsproj.
error FS0192 : internal error : primDestForallTy: not a forall type [/Users/joakimsjohaug/Projects/fsharp/nobina/app/src/app.fsproj]

Build FAILED.

error FS0192 : internal error : primDestForallTy: not a forall type [/Users/joakimsjohaug/Projects/fsharp/nobina/app/src/app.fsproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:04.90

Related information

Operating system: macOS 10.14.4
Branch: master
.NET: 2.2.103
Editing Tools: Visual Studio Code

The text was updated successfully, but these errors were encountered:

forki · 2019-04-14T07:22:13Z

I looked at this yesterday and it's easy to reproduce. Unfortunately it does not show line numbers. It also does not reproduce in the IDE. Only if you run a build. I tried to make the repro smaller but failed. Joakim Sjøhaug <[email protected]> schrieb am Sa., 13. Apr. 2019, 23:57:

…

On *dotnet build* or *dotnet run yarn-watch* compiler fails with an internal error. Repro steps 1. Clone my repository from here <https://github.com/JoakimSjo/fable-react-nobinaApp> 2. Run *dotnet build* or *dotnet run yarn-watch* inside "src" folder. Expected behavior Compilation succede. Actual behavior Compilation fails with following error: Microsoft (R) Build Engine version 15.9.20+g88f5fadfbe for .NET Core Copyright (C) Microsoft Corporation. All rights reserved. Restore completed in 24.31 ms for /Users/joakimsjohaug/Projects/fsharp/nobina/app/src/app.fsproj. Restore completed in 48.86 ms for /Users/joakimsjohaug/Projects/fsharp/nobina/app/src/app.fsproj. error FS0192 : internal error : primDestForallTy: not a forall type [/Users/joakimsjohaug/Projects/fsharp/nobina/app/src/app.fsproj] Build FAILED. error FS0192 : internal error : primDestForallTy: not a forall type [/Users/joakimsjohaug/Projects/fsharp/nobina/app/src/app.fsproj] 0 Warning(s) 1 Error(s) Time Elapsed 00:00:04.90 Related information - Operating system: macOS 10.14.4 - Branch: master - .NET: 2.2.103 - Editing Tools: Visual Studio Code — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6528>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNPUvWj54a1V-__GcoTFavgQdEew7ks5vglK9gaJpZM4cuStP> .

TIHan · 2019-04-15T18:00:35Z

I can look at this one.

cartermp · 2020-08-13T01:16:35Z

@joakimsjo Do you still see this one? The repro has some older dependencies and it could be that a fix is in place, but not present in the current project.

Zaid-Ajaj · 2020-12-15T06:39:32Z

I just came across this issue and have no idea where to go from here :/ using latest net5 sdk and it seems like another FSharp.Core version resolution issue.

dsyme · 2020-12-15T14:11:26Z

I just came across this issue and have no idea where to go from here :/ using latest net5 sdk and it seems like another FSharp.Core version resolution issue.

Could you make a minimal repro? And try changing referenced FSharp.Core to see if that makes a difference? Also --langversion:4.7

Just anything to reduce the matrix of possibilities and causes

dsyme · 2020-12-15T14:12:46Z

Also, it may be possible to propagate a range parameter down to primDestForallTy to give a better location error on this failure.

cartermp · 2020-12-15T16:25:08Z

I've only ever seen this manifest in fable projects (via bug reports) and so there is likely some subtle issue in the interplay of FSharp.Core there

ThisFunctionalTom · 2020-12-16T09:36:22Z

We have the same issue in our project and we found out following:

We use sdk 3.1 to compile our solution
We have this problem only with our Client.fsproj (it is a Fable project referencing Fable.Core 3.2.0)
When compiling Client.fsproj we get "primDestForallTy" error
When we changed reference in Client.fsproj to Fable.Core 3.1.6 everything works
Fable.Core 3.2.0 depends on FSharp.Core >= 5.0
Fable.Core 3.1.6 depends on FSharp.Core >= 4.7.1

TLDR: Changing reference to Fable.Core 3.1.6 solved our problem 😅

I hope this information can help finding the issue.

ThisFunctionalTom · 2020-12-16T11:22:20Z

I followed the trail and made a smallest repro I could come up with.

In the App.fs if you comment out Program.withDebugger compilation works and with this line it does not.

module App

open Elmish
open Elmish.React

#if DEBUG
open Elmish.Debug
#endif

Program.mkProgram Index.init Index.update Index.view
|> Program.withReactSynchronous "elmish-app"
// #if DEBUG
// |> Program.withDebugger
// #endif
|> Program.run

also with Fable.Core 3.1.6 compilation works and with 3.2.0 it does not.

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>netcoreapp3.1</TargetFramework>
    </PropertyGroup>
    <ItemGroup>
        <Compile Include="Index.fs" />
        <Compile Include="App.fs" />
    </ItemGroup>
    <ItemGroup>
      <PackageReference Include="Fable.Core" Version="3.1.6" />
      <PackageReference Include="Fable.Elmish" Version="3.1.0" />
      <PackageReference Include="Fable.Elmish.Debugger" Version="3.2.0" />
      <PackageReference Include="Fable.Elmish.React" Version="3.0.1" />
      <PackageReference Include="Fable.React" Version="7.2.0" />
    </ItemGroup>
</Project>

So, I guess it has to be something with Fable.Core 3.2.0 and implementation of Program.withDebugger in Fable.Elmish.Debugger.

ThisFunctionalTom · 2020-12-16T13:48:05Z

I tried following:
Remove Fable.Elmish.Debugger nuget package and add the two source files Fable.Import.fs and Elmish.Debugger.fs from elmish/debugger repo branch v3.x to my project and then everything works again. 🤔

zanaptak · 2020-12-23T05:13:26Z

Similar to @ThisFunctionalTom's repro, it's not only Fable.Elmish.Debugger that triggers this. It also triggers with Fable.Core + Feliz, but only in combination of newer versions of both. You can downgrade one or the other, either a) Fable.Core to 3.1.6, or b) Feliz to 0.5.0, and the error goes away even if you leave the other one at the newer version.

Repro project here, you can dotnet build on different branches:

branch	Fable.Core	Feliz	error?
master	3.2.0	0.6.0	yes
downgradeFeliz	3.2.0	0.5.0	no
downgradeFable	3.1.6	0.6.0	no

Things that do not affect the error:

FSharp.Core 5.0.0 or 4.7.2 -- error still occurs
TargetFramework net5.0, netcoreapp3.1, or netstandard2.0 -- error still occurs
LangVersion 5.0, 4.7, or preview -- error still occurs
build with SDK 5.0.101, 3.1.302, or 2.1.403 -- error still occurs

cartermp · 2020-12-23T05:38:25Z

One quirk I noticed, just a shot in the dark, is that Fable.Core depends on FSharp.Core 4.7.0 and Feliz depends on FSharp.Core 4.7.2. Fable.Core should really update to 4.7.2 at least.

alfonsogarciacaro · 2020-12-23T07:05:27Z

Thing is I pushed 3 Fable.Core releases recently:

3.2.0 depended on FSharp.Core 5.0.0, because I built it with dotnet sdk 5 and that was the default
3.2.1 explicitly depended on FSharp.Core 4.7.2 (with <PackageReference Update=) to avoid incompatibility with other existing Fable libraries
3.2.2 reduced the requirement to FSharp.Core 4.7.0. I did this to match Fable.Core 3.1.5 (users said that one worked) but with no luck.

So 3.2.1 already referenced 4.7.2 but it was causing problems too. Users say the problem appears with all Fable.Core 3.2.x versions. I myself haven't seen this error on macOS :/

uxsoft · 2020-12-23T14:18:02Z

I can reproduce the error on both Windows and macOS, using Fable.Core 3.2.x.

In my case Removing Fable.Elmish.Debugger doesn't fix the issue so as suggested above I think it's caused by more packages.

I'm using FSharp.Core 5.0.0

Luiz-Monad · 2020-12-23T21:01:25Z

We have the same issue in our project and we found out following:
* We use sdk 3.1 to compile our solution

* We have this problem only with our Client.fsproj (it is a Fable project referencing Fable.Core 3.2.0)

* When compiling Client.fsproj we get "primDestForallTy" error

* When we changed reference in Client.fsproj to Fable.Core 3.1.6 everything works

* Fable.Core 3.2.0 depends on FSharp.Core >= 5.0

* Fable.Core 3.1.6 depends on FSharp.Core >= 4.7.1
TLDR: Changing reference to Fable.Core 3.1.6 solved our problem 😅

I hope this information can help finding the issue.

Had the same problem, pinning versions solved it.

Packet.lock
Packet.dependencies

njlr · 2020-12-23T21:24:43Z

This combo worked for me:

nuget FSharp.Core 5.0.0
nuget Fable.Core 3.1.6
nuget Fable.Elmish
nuget Fable.Elmish.React
nuget Feliz 1.31.1

    <TargetFramework>netstandard2.1</TargetFramework>

Luiz-Monad · 2020-12-23T21:50:50Z

Yeah, 3.1.6 will work with any framework. In my tests 3.2 failed always. I'm leaving it pinned.
fable-compiler/Fable#2326 (comment)

msugakov · 2020-12-24T09:43:17Z

With just

nuget Fable.Core = 3.1.6

I get a different build error (see thoth-org/Thoth.Json#45):

FSC : error FS0193: The module/namespace 'Encode' from compilation unit 'Thoth.Json' did not contain the val 'ValLinkagePartialKey(generateEncoder)'

The following combination worked:

nuget Fable.Core = 3.1.6
nuget Fable.Elmish.Debugger = 3.2.0

TIHan · 2021-01-06T01:43:19Z

Minimal repo:

module App

let view () =  
    Fable.Helpers.ReactNative.view []

TIHan · 2021-01-08T03:24:14Z

Ok, spent a large portion of time looking at this.

The issue is a bit complex, but it relates to an API change in Fable.Core's JsInterop module.
In the past, the function definition for createObj looked like this:

// Fable.Core 3.1.6
let createObj (fields: #seq<string*obj>): obj = jsNative

Today, it's this:

// Fable.Core 3.2.0 >
let createObj (fields: seq<string*obj>): obj = jsNative

The difference is that the former has a type argument due to the use of # while the latter does not.

Then, as an example, in the Feliz library's Interop module,
there is a method definition:

// Feliz 0.6.0
type Html = ...
    static member inline div (value: string) = Interop.reactElement "div" (createObj [ "children" ==> [| value |] ])

With Feliz 0.6.0 and Fable.Core 3.2.0, this simple example fails compilation:

open Feliz

let view () =
    Html.div "test"

What I think is happening:

If the Feliz library is compiled using Fable.Core 3.1.6, then using that Feliz library with a version of Fable.Core's library with the createObj API change effectively breaks it. The reason why it fails at compile time is because div is marked as inline - the Feliz library has a serialized expression of div that assumes createObj has a type-argument when in reality it does not; at compile time it explodes because it is expecting the type argument when it actually doesn't exist on createObj's actual definition.

That isn't precisely the problem, but more or less it is - the nuance is in the generic first-class values with forall types.

The easiest solution to this would be to re-compile the Feliz library (or other libraries) with the new version of Fable.Core.

I don't know if it's the right solution to fix this issue in the compiler - though I think we should provide a much better error message indicating that it isn't compatible.

alfonsogarciacaro · 2021-01-08T06:09:17Z

Thanks a lot for this @TIHan. I'm an idiot, I did go through the changes from Fable.Core 3.1.6 to 3.2 looking for something out of place, but missed that one. Would it work if I push a new version of Fable.Core going back to the let createObj (fields: #seq<string*obj>) signature? I don't remember exactly why I did that change I need to check the commit.

zanaptak · 2021-01-08T17:53:37Z

Thanks for the investigation and update @TIHan and @alfonsogarciacaro. The newest Fable.Core 3.2.3 with this update now compiles correctly for me, tested with both Feliz and Fable.Elmish.Debugger.

uxsoft · 2021-01-09T19:03:30Z

Works!

tforkmann · 2021-01-11T09:26:37Z

Works! Had the same issue!

JanBizub · 2021-01-26T15:23:29Z

Works! Had the same issue!

dsyme · 2022-03-30T05:20:03Z

Closing out this old issue

cartermp added Area-Compiler Bug labels Apr 14, 2019

cartermp added this to the 16.1 milestone Apr 14, 2019

TIHan self-assigned this Apr 15, 2019

cartermp modified the milestones: 16.1, 16.2 Apr 23, 2019

cartermp modified the milestones: 16.2, Backlog Apr 30, 2019

jaredpar unassigned TIHan May 15, 2019

abelbraaksma mentioned this issue Aug 9, 2020

FS0192 "destRefTupleTy: not a reference tuple type" #9903

Closed

dsyme added the Impact-Low (Internal MS Team use only) Describes an issue with limited impact on existing code. label Aug 26, 2020

cartermp modified the milestones: Backlog, Backlog - Lower Priority Aug 31, 2020

cartermp modified the milestones: Backlog - Lower Priority, Backlog Oct 28, 2020

alfonsogarciacaro mentioned this issue Dec 22, 2020

Error in dotnet build: "primDestForallTy: not a forall type" when referencing Fable.Core >= 3.2.1 fable-compiler/Fable#2326

Closed

ThisFunctionalTom mentioned this issue Dec 23, 2020

Update FSharp.Core dependency to at least 4.7.2 fable-compiler/Fable#2334

Closed

piaste mentioned this issue Jan 4, 2021

Fable 3 handles <TreatWarningsAsErrors> in referenced projects differently than Fable 2 fable-compiler/Fable#2288

Closed

TIHan self-assigned this Jan 8, 2021

alfonsogarciacaro mentioned this issue Nov 3, 2021

Tooling support for binary breaking changes in components #12328

Open

alfonsogarciacaro mentioned this issue Dec 15, 2021

[Proposal] Intersection types? fable-compiler/Fable#2655

Open

dsyme closed this as completed Mar 30, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Compile error: "primDestForallTy: not a forall type" #6528

Compile error: "primDestForallTy: not a forall type" #6528

joakimsjo commented Apr 13, 2019

forki commented Apr 14, 2019 via email

TIHan commented Apr 15, 2019

cartermp commented Aug 13, 2020

Zaid-Ajaj commented Dec 15, 2020

dsyme commented Dec 15, 2020

dsyme commented Dec 15, 2020

cartermp commented Dec 15, 2020

ThisFunctionalTom commented Dec 16, 2020 •

edited

Loading

ThisFunctionalTom commented Dec 16, 2020 •

edited

Loading

ThisFunctionalTom commented Dec 16, 2020

zanaptak commented Dec 23, 2020

cartermp commented Dec 23, 2020

alfonsogarciacaro commented Dec 23, 2020

uxsoft commented Dec 23, 2020

Luiz-Monad commented Dec 23, 2020 •

edited

Loading

njlr commented Dec 23, 2020

Luiz-Monad commented Dec 23, 2020 •

edited

Loading

msugakov commented Dec 24, 2020

TIHan commented Jan 6, 2021

TIHan commented Jan 8, 2021 •

edited

Loading

alfonsogarciacaro commented Jan 8, 2021

zanaptak commented Jan 8, 2021

uxsoft commented Jan 9, 2021

tforkmann commented Jan 11, 2021

JanBizub commented Jan 26, 2021

dsyme commented Mar 30, 2022

Compile error: "primDestForallTy: not a forall type" #6528

Compile error: "primDestForallTy: not a forall type" #6528

Comments

joakimsjo commented Apr 13, 2019

Repro steps

Expected behavior

Actual behavior

Related information

forki commented Apr 14, 2019 via email

TIHan commented Apr 15, 2019

cartermp commented Aug 13, 2020

Zaid-Ajaj commented Dec 15, 2020

dsyme commented Dec 15, 2020

dsyme commented Dec 15, 2020

cartermp commented Dec 15, 2020

ThisFunctionalTom commented Dec 16, 2020 • edited Loading

ThisFunctionalTom commented Dec 16, 2020 • edited Loading

ThisFunctionalTom commented Dec 16, 2020

zanaptak commented Dec 23, 2020

cartermp commented Dec 23, 2020

alfonsogarciacaro commented Dec 23, 2020

uxsoft commented Dec 23, 2020

Luiz-Monad commented Dec 23, 2020 • edited Loading

njlr commented Dec 23, 2020

Luiz-Monad commented Dec 23, 2020 • edited Loading

msugakov commented Dec 24, 2020

TIHan commented Jan 6, 2021

TIHan commented Jan 8, 2021 • edited Loading

alfonsogarciacaro commented Jan 8, 2021

zanaptak commented Jan 8, 2021

uxsoft commented Jan 9, 2021

tforkmann commented Jan 11, 2021

JanBizub commented Jan 26, 2021

dsyme commented Mar 30, 2022

ThisFunctionalTom commented Dec 16, 2020 •

edited

Loading

ThisFunctionalTom commented Dec 16, 2020 •

edited

Loading

Luiz-Monad commented Dec 23, 2020 •

edited

Loading

Luiz-Monad commented Dec 23, 2020 •

edited

Loading

TIHan commented Jan 8, 2021 •

edited

Loading