-
Notifications
You must be signed in to change notification settings - Fork 299
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
Potential false positive in complex method #103
Comments
Reading the code, I agree that the access is safe. The invariant that holds just before the if condition is Going to mark as low priority for now, though it'd be great to handle this case eventually. |
This PR addresses an issue I found in [NullAway issue #103](uber/NullAway#103), where compile-time errors were caused by missing methods and types. The missing methods were caused by the following: **1) Methods not preserved** Foo extends (abstract) Bar extends [Some JDK interface] If Bar contains an abstract method also present in the JDK interface, those implementations in Foo were removed while the abstract definition was maintained in Bar, causing compile-time errors. A check was added to ensure that all super abstract methods did not contain anything that needed to be preserved (i.e. when in Foo, instead of just checking Bar, we check Bar and the JDK interface). **2. Classes not preserved** If a non-target class needs its method implementations to be preserved, and some of its return/parameter types are solvable but were untracked so far by `usedTypeElements`, their ancestors were not preserved. For example, if a method visited by `MustImplementMethodsVisitor` is of type `PeekingIterator<E>` which extends `Iterator<E>`, the `extends Iterator<E>` portion is kept in the original definition but its import statement was removed, leading to compile-time errors. The new approach to this is, if a type element was not previously in `usedTypeElements`, all of its ancestors (interfaces and super classes) would also be marked for preservation. A test case can be found in `Issue103Test`. Thanks!
I have a complex method that, sadly, seems worse when broke apart. So while none of my tests fail, I cannot be certain myself that there is not a bug.
However, the loop terminates earlier on the condition that both
candidate
andvictim
are null. This error is reported in a block when thevictim
is null, so therefore thecandidate
cannot be. I would consider this a perfect example where I'd want to trust a data flow analysis over my own, but I don't think it is correct. Due to the reassignments and looping, it may have gotten confused.The text was updated successfully, but these errors were encountered: