Do not flag match types as Deferred and amend #20077
#20147
Conversation
Both observe different behaviours match type reductions depending on whether they are compiled together or separately. They both compile only with separate compilation.
This already wasn't the case for unpickled match types, which caused varying results for `ImplicitRunInfo#isAnchor`, by not reaching the `isMatchAlias` condition. Ensures both scala#20071 and scala#20136 each have the same result, when compiled with a classpath dependency as when merged. Note that they both still fail (20071 compiles but shouldn't), but at least do so consistently. Also update TreeUnpickler MATCHtpt doc to align with changes from scala#19871 Co-authored-by: Guillaume Martres <[email protected]>
Fixes scala#20136 Co-authored-by: Guillaume Martres <[email protected]>
| @@ -1542,8 +1542,6 @@ class TreeUnpickler(reader: TastyReader, | |||
| // as the reduction of the match type definition! | |||
| // | |||
| // We also override the type, as that's what Typer does. | |||
| // The difference here is that a match type that reduces to a non-match type | |||
| // makes the TypeRef for that definition will have a TypeAlias info instead of a MatchAlias. | |||
There was a problem hiding this comment.
Also update TreeUnpickler MATCHtpt doc to align with changes from #19871
I don't think this change is correct. #19871 is about making aliases to an applied type, even if that is backed by a match type, be a TypeAlias rather than a MatchAlias.
What we're dealing with here is a straight alias to a match type, except the match type immediately normalises to a non-match type. When compiling from source we simplify it and thus give the alias a TypeAlias. With this change, when we're unpickling we also simplify and thus give the alias a TypeAlias.
If you can find a clearer way to express that, we should keep this information.
There was a problem hiding this comment.
Indeed, I agree this shouldn't be impacted by the changes in #19871.
But I'm now not sure about which cases get reduced more from the Unpickler than when from the Typer ?
There was a problem hiding this comment.
Nothing more. The point is the have the same definition, whether from source code or from tasty, have the same info, so that differences in MatchAlias and TypeAlias don't become a factor.
There was a problem hiding this comment.
So assuming the match type reduces to non match type, won't they all have a TypeAlias now ?
There was a problem hiding this comment.
Correct, but only because I added overwriteType here. The deleted comment is part of (attempting to!) explain that and shouldn't have been removed.
There was a problem hiding this comment.
Okay, so I agree we need tpt.overwriteType(tpt.tpe.normalized) and that it is because that's what Typer does.
Still, it was my understanding that the Typer and Unpickler now use AliasingBounds in a consistent way, so I don't understand how there is a difference here for the TypeRef for that definition.
There was a problem hiding this comment.
By "The difference here" I meant "The reason that is important to do is because..."
Match types are already not flagged as
Deferredwhen unpickled.This caused varying results for
ImplicitRunInfo#isAnchor, by not reaching theisMatchAliascondition when created from the Namer.Ensures both #20071 and #20136 each have the same result, when compiled with a classpath dependency as when merged into a single file.
Fixes #20136