Files with pattern matching need to be recompiled if union cases change

[tomcl]

Description

Umm... In some circumstances a multiple file all one project F# program, watch-compiled by nagareyama, does not recompile when it should.

At least it seems to be that. I have found now 2 or 3 times during dev that some source changes lead to very peculiar incomprehensible (they look like compile errors) bugs that vanish when I stop watching and recompile from scratch.

The common thread would appear to be that when I add a case to a D.U., even though it works, some subsequent match expressions (in different modules) go to the wrong case. It might be something else, but this problem definitely occurs when I add cases to D.U.s in base types and then work on code that uses them in other modules.

In all cases the apparent intractable bug goes away when I next fully compile.

Any ideas?

I'll keep an eye on it and try to repro.

Repro code

Not a hope, as yet.

• Fable version: nagareyama 3.0.5
• Operating system win 10

[alfonsogarciacaro]

Ah, I think I saw something similar but I thought it was fixed before the stable release. Does this happen when you add the new case in a position other than the end? This causes the indices of the union cases to change so all files calling the union constructor must change. This should be done in latest version.

[tomcl]

Well this is one of those "don't realise till afterwards" things but yes, my guess is that it happens when a case not at end is added. I have been doing that. I am noticing it because it is a really unpleasant error to diagnose... Great that it will be fixed.

[alfonsogarciacaro]

Ah, I'm thinking now maybe the problem comes from the case tests (as in pattern matching). These are not being recompiled atm. We can solve the issue trying to recompile them too or using something to identify the case that's not depending on the order, like or probably better just the case name as we did in Fable 2. This may be related to #2279, what do you think @ncave?

[tomcl]

Yes, I think case tests. I have sort of spidey feeling that it was going down wrong match branch.

[tomcl]

You need consecutive integers for fast dispatch I guess. So you need to recompile? It is not a big deal recompiling since changing types is not so common a thing.

[alfonsogarciacaro]

I've published 3.1 with a fix, can you please try?

[tomcl]

OK, so I switched the position of two cases in my D.U.

(1) lots of files watch-compiled (good)
(2) it did the wrong thing (expected)
(3) I force-reloaded
(4) it then worked fine.

So that is as good as i can get to thinking this (v nasty) bug is now fixed.

Just a warning - if there are any more compiler bugs my 70 or so HLP students this Term are likely to find them...

:)

[alfonsogarciacaro]

Great, thanks a lot for confirming so quickly! Looking forward for the bugs reported by your students (I hope they're not too many) :)