msridhar
commented
10 months ago Thanks for the report @g-jiannan and for the candidate fix! Before we land any potential fix here, I'd like to try to create a test case that reproduces this issue. Can you share the return type of the sharedPreferences.getAll() method that is called in your code excerpt? Or if you could come up with a crashing test case that would be really useful.
I'm not pretty sure the root cause but it turns out the problem is that AccessPathNullnessPropagation#isCallToMethod is not so robust: it expects Set.iterator() but the the receiver type is resolved as Collection unexpectedly sometimes.
This is surprising to me. We have code that specifically looks for a call to keySet() on a java.util.Map, and that method is declared to return a Set. In that case, I don't see how the receiver type of the subsequent iterator() could be Collection. But we do have a crash so I must be missing something.
A quick fix is leverage errorprone matchers and I'll send pull request soon.
This code is performance critical, so my instinct is to not use Error Prone matchers here, at least not without careful understanding of the performance implications. If we can reproduce the crash, we may be able to find a more localized fix.
Thanks again!
g-jiannan
lazaroclapp
When we try to adopt NullAway (version 0.10.16), following exception is thrown unexpectedly sometimes:
The reported code
for (String key : sharedPreferences.getAll().keySet()) {looks trivial and the code pattern is already covered by theNullAwayKeySetIteratorTests. I'm not pretty sure the root cause but it turns out the problem is that AccessPathNullnessPropagation#isCallToMethod is not so robust: it expects Set.iterator() but the the receiver type is resolved as Collection unexpectedly sometimes.A quick fix is leverage errorprone matchers and I'll send pull request soon.