Fix MT separate compilation bug (bis)

[dwijnand]

Like I said in #18398, there are several factors involved, and I'd be happy to fix one or more of those causes, in alternative to hot-fixing specific tasty trees.

[dwijnand]

Looking at pos/i15183. It's a test using separate compilation. With my change it stopped compiling, but with or without my change it doesn't compile in joint compilation either. So my change made it consistently not compile.

The failure is in whether Decoder.summonTuple is eligible. When its result type isn't normalized then Tuple.Map[H *: T, Decoder] is compatible with the desired Tuple.Map[(Local.type, Prod.type), Decoder]. But if it is normalized and I also normalize the desired type, then Decoder[H] *: Tuple.Map[T, Decoder] is still not compatible with (Decoder[Local.type], Decoder[Prod.type]), despite it being so if T is Tuple1[Prod.type].. 😕

should use? Tuple.Map[H *: T, Decoder]
to find: Tuple.Map[(Local.type, Prod.type), Decoder]

should use? Decoder[H] *: Tuple.Map[T, Decoder]
to find: (Decoder[Local.type], Decoder[Prod.type])


should use? Tuple.Map[T, Decoder]
to find: (Decoder[Prod.type])

[soronpo]

@dwijnand is there a solution in sight?

[dwijnand]

I went down the road for a long time (weeks) trying to address the general problem of making Typer and Unpickler simplify and replace types in exactly the same way - and that got very complicated. I'm taking a break on this PR, but I haven't given up on fixing this issue yet.

[soronpo]

Is this fixed under the new match type implementation? If so, I think it is best to revert back to what worked for 3.3.0 and leave that as is for 3.3.x.

[dwijnand]

The "new match type implementation" is only about match types reduction, in terms of whether they reduce or not and to what, in a more constrained fashion than we currently do (meaning, things that one would hope are reduced stop reducing). But it says nothing about whether those reductions should be further simplified or normalised (which was what the original #18073 was about), or whether typer and/or unpickler should simplify and overwrite their tree types (which was what the previous #18398 and this PR are about). I don't think we can revert back to what worked in 3.3.0 as we'd be causing a regression in #16596, for example.

[soronpo]

I don't think we can revert back to what worked in 3.3.0 as we'd be causing a regression in #16596, for example.

3.2.x was not an LTS release.

[dwijnand]

Replaced with #18786.