Use upper bound of abstract types in exhaustivity checking #23909
Conversation
| classSym.is(Case) || | ||
| (tpw.isInstanceOf[TypeRef] && { | ||
| val tref = tpw.asInstanceOf[TypeRef] | ||
| tref.symbol.isOpaqueAlias && !tref.info.hiBound.isNothingType |
There was a problem hiding this comment.
Should I extract this logic into a separate function? If so, where would be a good place to put it?
| else NoType | ||
| }.filter(_.exists) | ||
| parts | ||
| case tref: TypeRef if tref.symbol.isOpaqueAlias && !tref.info.hiBound.isNothingType => |
There was a problem hiding this comment.
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.
c70aaa3
Is this correct?
There was a problem hiding this comment.
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.
I see, thank you for the review.
nox213 changed the title nox213 changed the title 4 participants
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.