-
Notifications
You must be signed in to change notification settings - Fork 356
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
Unsoundness in MustCallChecker (and RLC) for functional interfaces #6823
Comments
I just looked into the anonymous class case for a bit. I think maybe the issue is in Line 2759 in e1dc973
For the Line 2783 in e1dc973
But for the anonymous class case, this qualifier never gets properly added to the type of the @smillst does the above look like a problem to you? |
Yes, I've got a fix: #6837. |
Lambda and method reference cases are trickier. I'm still thinking about them. |
I'm not convinced that the lambda and the method reference examples should issue warnings. Can you give an example where resource leak occurs using a lambda or method reference? |
It's a little contrived, but maybe something like this: abstract class ResourceLambda {
public void go(Path f) throws IOException {
InputStream in = Files.newInputStream(f);
runAndThen(in::close);
}
@FunctionalInterface
@InheritableMustCall("close")
public interface CloseProcedure {
void close() throws IOException;
}
abstract void runAndThen(CloseProcedure closeProcedure);
} The resource There is no way to annotate this code so that it passes, but it illustrates that a Aside from resource leaks, I can imagine (subversive?) uses of the RLC to ensure that a program eventually calls certain methods---even if the reason for calling those methods is something other than "close file descriptors". |
Although, it might be best for the RLC to reject the |
I would not call this subversive. We always had an idea of others potentially using this checker for other "must-call" methods that do not necessarily relate to resource leaks. In fact, I worked with an undergrad to tinker around with using the RLC to check always-unlock-after-lock properties with Java ReentrantLocks. (It didn't seem to work out due to uses in fields that the RLC doesn't handle all that well, though we didn't push it too hard.)
I'm not sure about this either. It does seem to me that if we could fix the computed must-call types of lambdas and method refs that might be good in general, potentially for future type systems also. |
The types are computed correctly, they just aren't checked. (Checking an assignment of a lambda or a method reference checks for congruence.) See |
This example creates a
Closeable
functional interface and makes new instances of it in a few sneaky ways:I would expect all 5 cases would report an error, but only the first two do:
I did my best to debug this one, but the problem actually seems to be in the "framework" part of the Checker Framework, and not in the Must Call Checker specifically---although I'm not quite knowledgeable enough to know for sure. It seems like
new ClassName()
is always assigned the correct type@MustCall({"close"})
, but other ways of constructing an instance of the class do not get the right inherited annotations.The text was updated successfully, but these errors were encountered: