-
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 reachability by retaining spaces of Prod params #14118
Conversation
When intersecting a product type space with a type space, if the two types aren't related, we must retain the spaces of the parameters, otherwise the intersection will represent a bigger space of values that it should (leading to a false positive unreachability warning). I actually think that the first condition, `isSubType(tp1, tp2)`, should be true, because `Bar` is a subtype of `Foo[X]`, provided `X` is instantiated to `Nothing`. Maybe that's not isSubType but something else (because we want forSome X, not forAll X). But, either way, fixing that the intersection doesn't overpromise (i.e. lie) is a good fix anyways.
This is what the log looks like for the part I mean. I've fixed this now by making the intersection return
|
This fixes the issue, so it's mergeable as it is, but I'm asking as I would like to see if I can improve it further. |
Creating new type variables looks like GADT territory. Maybe @abgruszecki can comment. For the space logic it looks OK to me, but I am no expert. @liufengyun could you take a quick look? |
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 am not an expert, so I can't comment on the logic. It looks reasonable to me and I found no other problems.
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, thanks for the fix @dwijnand 👍
if (!isSameUnapply(fun1, fun2)) intersectUnrelatedAtomicTypes(tp1, tp2) | ||
if (!isSameUnapply(fun1, fun2)) intersectUnrelatedAtomicTypes(tp1, tp2) match | ||
case Typ(tp, _) => Prod(tp, fun1, ss1) | ||
case sp => sp |
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.
Aside: We could experiment by introducing a space called Unknown(tp: Type)
for this case later.
Edited: Sorry, I meant the case above (the 1st case).
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.
The case is only for Empty, when the two types are provably disjoint, so I'm not sure what we'd want to preserve the type for. But I'm not against the idea.
Btw, I sort of introduced this regression when I made the change in 202b63e without realising I was forgetting the subpatterns of the product spaces (the components/params). |
When intersecting a product type space with a type space, if the two
types aren't related, we must retain the spaces of the parameters,
otherwise the intersection will represent a bigger space of values that
it should (leading to a false positive unreachability warning).
I actually think that the first condition,
isSubType(tp1, tp2)
, shouldbe true, because
Bar
is a subtype ofFoo[X]
, providedX
isinstantiated to
Nothing
. Maybe that's not isSubType but somethingelse (because we want forSome X, not forAll X). But, either way, fixing
that the intersection doesn't overpromise (i.e. lie) is a good fix
anyways.