-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Fix #1490: type test of union types via type alias #1491
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
Conversation
*/ | ||
def erasure(tp: Type)(implicit ctx: Context): Type = | ||
erasureFn(isJava = false, semiEraseVCs = false, isConstructor = false, wildcardOK = false)(tp)(erasureCtx) | ||
* @param eraseOrType Whether erase OrType to its lowest uppper bound |
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.
I would write Whether OrType should be erased to its lowest upper bound
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.
Thanks, will address in the next commit.
I am missing the context. Why do we need to make this distinction? The way it is done it adds a significant cost to compiler complexity. Adding a new boolean parameter to a core method should not be taken lightly, because you just have doubled all possible error scenarios! |
|
By the way, the same thing is true in https://github.com/lampepfl/dotty/blob/master/src/dotty/tools/dotc/transform/IsInstanceOfEvaluator.scala which deals with erased values and so might end up doing an incorrect rewriting. |
@smarter That is how the previous implementation was done, but it doesn't handle the case in #1490 . A proper handling of #1490 would require us to recursively get rid of all type alias, that's part of the logic of type erasure. Either we need to find a way to reuse the type erasure code, or we have to duplicate some of its code. |
Question: What should the imlementation
be? Erase | or not? I would assume erase. In which case, the whole thing does belong in isInstanceOfEvaluator. Can #1490 not be addressed by dealiasing? |
I think that in your example, |
I agree it's better to make the core simpler. Will follow the original approach by dealiasing. |
61e9372
to
9a5a517
Compare
LGTM |
Make type erasure accept one additional parameter:
eraseOrType
: Whether erase OrType to its lowest uppper bound