Fable: (dev2.0) Constructor mapping issue

Created on 29 Jun 2018  路  8Comments  路  Source: fable-compiler/Fable

If the .fsi constructor list does not match exactly the .fs implementation, the wrong constructor call is generated at call site.

  • when the number of constructors is different.
  • when the order of constructors is different.

Unfortunately since it's a code generation error, it will only manifest at runtime when it blows up.

Most helpful comment

@alfonsogarciacaro I wasn't able to reproduce it on small scale either (or I would've posted it), but it's not holding the REPL back since I fixed FCS signatures to match implementation. Perhaps later I'll spend some time to reproduce it, but I'm trying to finish the REPL benchmark, really close now and looking good.

All 8 comments

This is striking again. I guess that it'll be a problem not only for constructors but also for other overloaded methods. We need to be sure we're checking the ImplementationEntity instead of the symbol coming from the signature file.

Would it be possible to have some code to reproduce this?

I cannot reproduce this :/ I'm trying with the following:

// Domain.fsi
namespace Domain

type MyType =
  new: unit -> MyType
  member Value: int



// Domain.fs
namespace Domain

type MyType(i: int) =
  new () = MyType(9)
  member __.Value = i

// This version works too
// type MyType =
//     new (v) = { value = v }
//     new () = { value = 9 }
//     val value : int
//     member x.Value = x.value



// QuickTest.fs
open Domain

let foo = MyType()
printfn "%i" foo.Value

Fable correctly calls _Domain.MyType$$$$002Ector$$1. That is, the second constructor with overload index $$1.

@alfonsogarciacaro I wasn't able to reproduce it on small scale either (or I would've posted it), but it's not holding the REPL back since I fixed FCS signatures to match implementation. Perhaps later I'll spend some time to reproduce it, but I'm trying to finish the REPL benchmark, really close now and looking good.

That's great news, @ncave! Thanks a lot for all your work. I assumed you couldn't isolate it. I did write a potential fix but it's difficult to know whether it actually works without a test sample.

Can you please point at the signature file that caused the problem before editing? I also wonder why it's necessary to include the .fsi files to get the AST instead of just ignoring them.

@alfonsogarciacaro See for example the src/fsharp/symbols/Symbols.fsi.

Thanks! What would happen if we just filter out the .fsi files when parsing the project file before sending them to FCS. Would it work?

@alfonsogarciacaro I don't think so, the .fsi files are used a lot in FCS to set visibility, etc.
Let's just keep this issue open and come back to it in the future when we can reproduce.

I think this is fixed now with the overload hashes. Please reopen if it's still a problem.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

forki picture forki  路  3Comments

alfonsogarciacaro picture alfonsogarciacaro  路  3Comments

jwosty picture jwosty  路  3Comments

MangelMaxime picture MangelMaxime  路  3Comments

et1975 picture et1975  路  3Comments