-
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
Normalize for underlyingClassRef #20259
base: main
Are you sure you want to change the base?
Normalize for underlyingClassRef #20259
Conversation
Related to scala#20258 Here too, I would be fine with not normalizing, but in that case pos/i15827 should become a neg test.
@@ -1584,7 +1584,8 @@ object Types extends TypeUtils { | |||
else if (tp.symbol.isAliasType) tp.underlying.underlyingClassRef(refinementOK) | |||
else NoType | |||
case tp: AppliedType => | |||
if (tp.tycon.isLambdaSub) NoType | |||
if tp.isMatchAlias then tp.tryNormalize.underlyingClassRef(refinementOK) |
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.
For this and 20258, what if it's a match alias that doesn't normalise, don't you want to cascade to the later cases?
We don't really have an efficient way to do that (&& tp.tryNormalize.exists
:-/)
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.
It might be incorrect but I had intentionally not cascaded to the later cases here. I don't think any of them would return something other than NoType
on an unreducible match type.
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 think this goes against the spec. There is nothing in the spec supporting reducing match types when determining whether a type is a class type or not. And underlyingClassRef
is exactly the implementation of "is it a class type", AFAICT.
So yes, pos/i15827.scala
should probably be a neg test.
Related to #20258
Here too, I would be fine with not normalizing,
but in that case pos/i15827 should become a neg test.