If the .fsi constructor list does not match exactly the .fs implementation, the wrong constructor call is generated at call site.
Unfortunately since it's a code generation error, it will only manifest at runtime when it blows up.
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.
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.