-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make aliases of MatchAlias
es normal TypeAlias
es
#19871
Conversation
Alternative to #19854 |
5a6aa23
to
707eb77
Compare
MatchAlias
es TypeAlias
es instead of MatchAlias
esisMatch
false for applied MatchAlias
es
isMatch
false for applied MatchAlias
esisMatch
false for applied MatchAlias
es
c794c5f
to
93c3563
Compare
dbd43b6
to
add986b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's two more places where I wonder whether we need change too:
- The
MatchAlias
type test in TypeOps.simplify - The
MatchAlias
case in MatchType.InDisguise
Should those be if tp.isMatchAlias
and case AliasingBounds(alias) if tp.isMatchAlias
too?
@dwijnand For MatchType.InDisguise: object InDisguise:
def unapply(tp: AppliedType)(using Context): Option[MatchType] = tp match
case AppliedType(tycon: TypeRef, args) => tycon.info match
case MatchAlias(alias) => alias.applyIfParameterized(args) match
case mt: MatchType => Some(mt)
case _ => None
case _ => None
case _ => None If I am not mistaken, the I'm now wondering if you meant we might want to also accept these cases, independently of how they are affected by the aliasing changes ? An equivalent change on main would then be object InDisguise:
def unapply(tp: AppliedType)(using Context): Option[MatchType] = tp match
case AppliedType(tycon: TypeRef, args) => tycon.info match
case MatchAlias(alias) => alias.applyIfParameterized(args) match
case mt: MatchType => Some(mt)
case MatchType.InDisguise(mt) => Some(mt)
case _ => None
case _ => None
case _ => None which doesn't seem to break anything. Also, it looks like |
For |
Next is double-checking that we'll still function appropriately when we unpickle pre-3.4 tasty. I think it's dealt with the Unpickler change, right? |
The changes in Unpickler don't do anything more than factoring out the |
test performance please |
1 similar comment
test performance please |
performance test scheduled: 148 job(s) in queue, 1 running. |
Performance test finished successfully: Visit https://dotty-bench.epfl.ch/19871/ to see the changes. Benchmarks is based on merging with main (a36849f) |
263119a
to
c2030ea
Compare
isMatch
false for applied MatchAlias
esMatchAlias
es normal TypeAlias
es
This is necessary to ensure the implicit scope is consistent when involving match types, since they may or may not have been reduced before implicit search. We can for example get different results when loading from tasty than when in the same run. Fixes scala#20071
Make `isMatch` false for applied `MatchAlias`es, i.e. true only for `MatchType`s and higher-kinded abstraction of them. As a result, code using `isMatch` to choose between a `TypeAlias` and `MatchAlias` will now use a `TypeAlias` when aliasing a `MatchAlias`. Which in turn allows for better de-aliasing, since `dealias` only de-aliases standard type aliases. The logic for this distinction has also been extracted to the common `AliasingBounds` supertype. `tryNormalize` on `AppliedType`s should only attempt reduction if there is an underlying match type. This could previously be identified by a `MatchAlias` tycon. We now need a recursive check.
`def underlyingMatchType` had an `isMatchAlias` guard for `AppliedType`s. This used to be a quick check preventing unnecessary recursions and superType computations. But `isMatchAlias` is now itself mutually recursive with `underlyingMatchType`, so we cache it for AppliedTypes to alleviate this.
c2030ea
to
1dc5b99
Compare
Note that this PR is now based on #20077, |
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 #20071 and #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 #19871 Co-authored-by: Guillaume Martres <[email protected]>
Proposes to make
isMatch
true only forMatchType
s and higher-kinded abstraction of them.As a result, code using
isMatch
to choose between aTypeAlias
andMatchAlias
will now use aTypeAlias
when aliasing aMatchAlias
. Which in turn allows for better de-aliasing, sincedealias
only de-aliases standard type aliases.tryNormalize
onAppliedType
should only attempt reduction if there is an underlying match type. This could previously be identified by aMatchAlias
tycon. We now need a recursive check.Fixes #19821