-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Use upper bound of effectively sealed abstract types in exhaustivity checking #23909
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
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.
Should I extract this logic into a separate function? If so, where would be a good place to put it?
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.
None of this logic should be limited to opaque type aliases. It should work also for abstract type members, or not work for either. From the outside of its scope, an opaque type alias is an abstract type member. It makes no sense to treat them differently in this situation.
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.
c70aaa3
Is this correct?
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.
Seems correct to me, as far as that comment is concerned.
I cannot vouch for the whole PR. I am not familiar with pattern-match analysis.
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 see, thank you for the review.
Uh oh!
There was an error while loading. Please reload this page.
closes #23620
If the upper bound of an abstract type is not
sealedbut is effectively sealed, it is not handled correctly, since classSym could return a type that is notsealed(Object in the issue above).If the type were not abstract, it would pass the logic that checks whether it is an Or, And, etc., and would be handled properly.
This PR makes exhaustivity checking use the upper bound of abstract types that are effectively sealed.