Patch by Paul Peltz! I'm going to be addressing comments. The overall idea sounds great and the code seems to have all the necessary parts in place but I haven't looked at it very carefully so please comment.
Author's original description:
The NullabilityChecker has a very early policy decision that non-inlined property accesses will be inferred as returning nonnull, despite nullability annotations to the contrary. This decision eliminates false positives related to very common code patterns that look like this:
if (foo.prop) { [bar doStuffWithNonnull:foo.prop]; }
While this probably represents a correct nil-check, the analyzer can't determine correctness without gaining visibility into the property implementation.
Unfortunately, inferring nullable properties as nonnull comes at the cost of significantly reduced code coverage. My goal here is to enable detection of many property-related nullability violations without a large increase in false positives.
The approach is to introduce a heuristic: after accessing the value of a property, if the analyzer at any time proves that the property value is nonnull (which would happen in particular due to a nil-check conditional), then subsequent property accesses on that code path will be *inferred* as nonnull. This captures the pattern described above, which I believe to be the dominant source of false positives in real code.