No unboxing warning for `int x = integerArray[0]` due to bad CFG

[jeffrey-easyesi]

Both Checker Framework's NullnessChecker and NullAway fail to report the potential unboxing NPE here:

void f(@Nullable Integer[] array) { int x = array[0]; }

The problem is in CFG generation. CFGTranslationPhaseOne.visitArrayAccess adds the same ArrayAccessNode three times:

    extendWithNode(arrayAccess);
    extendWithNodeWithException(arrayAccess, arrayIndexOutOfBoundsExceptionType);
    extendWithNodeWithException(arrayAccess, nullPointerExceptionType);

A subsequent translateAssignment inserts the unboxing nodes after the first of the three. The final CFG looks like this

• RegularBlock([x, array, 0, array[0]])
• ExceptionBlock(array[0].intValue) - NullPointerException
• ExceptionBlock(array[0].intValue()) - RuntimeException+Error
• ExceptionBlock(array[0]) - ArrayIndexOutOfBoundsException
• ExceptionBlock(array[0]) - NullPointerException
• RegularBlock([x = array[0].intValue()])

and the extra copies of array[0] after .intValue() (a method call which implies a non-null receiver) cause the array[0] node to be deemed non-null.

I think this could be fixed by using a single extendWithNodeWithExceptions rather than duplicating the node.

EDIT: c471703 is the commit that introduced that, and also a few other places where a node is duplicated:

• visitCompoundAssignment, integer division/remainder
• visitBinary, integer division/remainder
• visitEnhancedForLoop, array access (This exception appears to be misplaced: an NPE would happen on .length, not on element access)

[mernst]

Thanks for the bug report and the suggested fix. We appreciate it.