-
Notifications
You must be signed in to change notification settings - Fork 290
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
Better handling of iterating over a map's key set #535
Comments
Some thoughts here. Consider the following code: import java.util.*;
class MyClass {
void test(Map m) {
for (Object o: m.keySet()) {
m.get(o);
}
}
} The Checker Framework generates the following control-flow graph for the This is the key part of it: Based on this CFG, I think we could pattern-match to handle the common case of code like the above that uses an enhanced for loop, as follows. During dataflow analysis, at an assignment node:
Checking for temporary variables like void mapReassign(Map m, Object o) {
if (m.containsKey(o)) {
m = new HashMap();
m.get(o).toString(); // null dereference!
}
} So the proposed handling would not add a new source of unsoundness. @lazaroclapp thoughts? |
This makes perfect sense to me. I assume we don't know of any other case where CF uses In that case, this seems perfectly safe to me (where safe is "as safe as our existing handling of |
#554) Fixes #535 Uses the strategy outlined in this comment: #535 (comment)
Example:
NullAway currently warns on the above code, but it does not warn for the following code:
Ideally, we would generalize our handling of the second case to handle the first case as well. Developers may find it strange that the second case is handled but not the first.
The text was updated successfully, but these errors were encountered: