-
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
Fix regression in provablyDisjoint #12786
Fix regression in provablyDisjoint #12786
Conversation
Good catch, I think the following will work (use case (tp1: TermRef, tp2: TypeRef) if isEnumValueOrModule(tp1) && !tp1.classSymbols.exists(_.derivesFrom(tp2.symbol)) =>
true |
That also doesn't work ( In general I don't think a test of the form |
It should be possible to conclude disjointness between an enum case and a class, that should be analogous to disjointness between a final class and a class which we handle in |
71a92a7
to
e184e75
Compare
@OlivierBlanvillain is this one good for a review? Or is the solution subject for discussion? |
e184e75
to
d52b365
Compare
d0f6397
to
e9271f3
Compare
e9271f3
to
4d6d72d
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.
LGTM
true | ||
case (tp1: TypeRef, tp2: TermRef) if isEnumValueOrModule(tp2) && !tp2.classSymbols.exists(_.derivesFrom(tp1.classSymbol)) => | ||
true | ||
case (tp1: TermRef, tp2: TypeRef) if isEnumValue(tp1) => |
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.
What is the consideration of using isEnumValue
instead of isEnumValueOrModule
here?
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.
So far I haven't found a need for it, the existing infrastructure doesn't need special treatment to handle modules...
#12549 introduced a regression in provablyDisjoint. The problem comes from the following case:
The
!tp1.classSymbols.exists(...)
is not sufficient, for instance if tp2 is unbounded type parameter that code can wrongly conclude that aTermRef
doesn't belong to that type.