-
Notifications
You must be signed in to change notification settings - Fork 357
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
It's unsound to refine the operand of an instanceof. #735
Conversation
However, the operand of an instance of is non-null if the instanceof is true
Add testcase |
I resolved the Daikon type-checking issue by adding annotations to Daikon indicating that num_samples can be called even when its receiver is under initialization. |
@wmdietl I would like to rebase this pull request into one commit before merging |
Is it unsound for type systems other than Nullness because the property is not checked at runtime? If that's the reasoning, shouldn't the same be done for casts? A cast without runtime check is equally unsound. |
@wmdietl is this pull request ok to merge? |
Yes
Correct, which is why a warning is issued if the cast is unsafe. |
So why not do the same thing for instanceof? Refine the type and issue a warning. The two seem equally unsound, so why treat them differently? |
We can do this, and I've opened an issue for this request, #762. However, we can't issue the warning without defaulting the reference type of the instanceof to top and it is not straight forward to do so. I would like to merge this pull request so that this fix appears in the release. |
That sounds like a good plan. I would add a reference from #762 back to this change, to have the basic implementation of the refinement feature. |
However, the operand of an instance of is non-null if the instanceof is true.
This changes cause a new (legitimate) Daikon type-checking error at this line. It's a method.invocation.invaild error on
pslice.num_samples();
.