Skip to content
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

Open
ben-manes opened this issue Jan 1, 2018 · 1 comment
Open

Potential false positive in complex method #103

ben-manes opened this issue Jan 1, 2018 · 1 comment

Comments

@ben-manes
Copy link

ben-manes commented Jan 1, 2018

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.

BoundedLocalCache.java:589: error: [NullAway] dereferenced expression candidate is @Nullable
        candidate.getPreviousInAccessOrder();
                 ^

However, the loop terminates earlier on the condition that both candidate and victim are null. This error is reported in a block when the victim is null, so therefore the candidate 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.

if (victim == null) {
  candidates--;
  Node<K, V> evict = candidate;
  candidate = candidate.getPreviousInAccessOrder();
  evictEntry(evict, RemovalCause.SIZE, 0L);
  continue;
} else if (candidate == null) { ... }
@msridhar
Copy link
Collaborator

msridhar commented Jan 3, 2018

Reading the code, I agree that the access is safe. The invariant that holds just before the if condition is (victim != null) || (candidate != null). Since under the if we know that victim == null, we also know candidate != null. This kind of logical reasoning is beyond what NullAway's data flow analysis can do right now. But, as discussed in #98, eventually we could add a more precise data flow analysis that runs when the existing analysis reports an error, and that more precise analysis could catch this case as well, depending on how it is designed.

Going to mark as low priority for now, though it'd be great to handle this case eventually.

kelloggm pushed a commit to njit-jerse/specimin that referenced this issue Jul 25, 2024
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!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants