weifanjiang / nullness_lite Goto Github PK

If the Checker Framework cannot infer a type argument, assume that the type argument is @nonnull.

https://courses.cs.washington.edu/courses/cse403/18sp/projects/project-ideas.html#Nullness_bug_detector

Review for Nullness_Lite

• It looks like you are all using code review to a great extent with assigning pull requests and haveing code review groups.
• You are using the issue tracker to identify bugs
• I cant tell how your work flow has been, I see that some of you have also forked the checker framework and made some changes, was this part of the project?
  or something you did before. Is there one central repository at 979216944/checker-framework that you all work on?
• I see lots of communication in pull requests.
• Looks like a lot of work has gone into testing the changes you have made to implement nullness_lite

I decided to review the merges you did with the master branch to see the bulk of the changes that were committed all at once. I read the issue tracker logs
as well to see what work had been happening there. I also read the documentation in the https://github.com/weifanjiang/Nullness_Lite repo

Assume that boxing of primitives is @pure: it returns the same value on every call.

https://courses.cs.washington.edu/courses/cse403/18sp/projects/project-ideas.html#Nullness_bug_detector

No initialization analysis; the checker assumes that every value is initialized.

Find programs satisfy the following requirements:
1. the nullness bugs they have should at least cover all features we are disabling.
2. contains 10k+ lines of codes each.

Unsolved Questions:
Q1. How to find such a program? Do we use Nullness Checker by assuming its report correct?
Q2. How many programs do we need for evaluation?

No invalidation of dataflow facts. Assume all method calls are pure, so method calls do not invalidate dataflow facts. Assume there is no aliasing, so field updates do not invalidate dataflow facts.

https://courses.cs.washington.edu/courses/cse403/18sp/projects/project-ideas.html#Nullness_bug_detector

During the process of implementing Nullness-Lite, we will mark each disabled feature
with its corresponding bugs.

Format:
Disabled Feature: Map key analysis
Bugs Unrevealed: Mutable keys corrupting maps

As one feature from Nullness Checker disabled, developers of Nullness-Lite should mark
down the annotations used in that feature.

Format:

1. Annotations disabled: @example ...
2. The URL to a commit that disabled the annotations above.

No map key analysis; assume that, at every call to Map.get, the given key appears in the map.

https://courses.cs.washington.edu/courses/cse403/18sp/projects/project-ideas.html#Nullness_bug_detector

I reviewed the commit history of the master branch in the main fork as well as the documentation present in the project repo.

• It's unclear whether the NullnessLite specific tests (.../nullness-liteoption/*) test for the catching of desired nullness errors or for the missing of undesired ones. NullnessLiteInit1 indicates expected errors for features that should be disabled and NullnessLiteInvalidDataflow1 has no such indications. If both are being tested, labelling which tests are testing for functionality and which are testing for lack thereof would be helpful.

• Tests seem to do a good job of covering all of the four features being disabled. I'm not familiar with how much the checker framework is involved with initialization checks and how much it needs testing, but the NullnessLiteInit tests seem sparse compared to the others.

• Good use of an issue tracker. Are the issue logs in the two separate repositories different in some way? It may be worth consolidating them to one place if not so that they can be more easily referenced.

• Pull request workflow is very clear. The request discussions and references to issues in the tracker give a good sense of the history of how problems are approached and fixed.

• Typo in README.md section title: 'IntelliJ (wihout "Infer Nullity" before...'