Nullables

An extractor for null comparisons

A pair of not-null sets, depending on whether a condition is true or false

A set of val or var references that are known to be not null, plus a set of variable references that are not known (anymore) to be not null

An extractor for null-trackable references

The nullability context to be used after a case that matches pattern pat. If pat is null, this will assert that the selector sel is not null afterwards.

A map from (name-) offsets of all local variables in this compilation unit that can be tracked for being not null to the list of spans of assignments to these variables. A variable can be tracked if it has only reachable assignments An assignment is reachable if the path of tree nodes between the block enclosing the variable declaration to the assignment consists only of if-expressions, while-expressions, block-expressions and type-ascriptions. Only reachable assignments are handled correctly in the nullability analysis. Therefore, variables with unreachable assignments can be assumed to be not-null only if their type asserts it.

Note: we track the local variables through their offset and not through their name because of shadowing.

The nullability context to be used for the guard and rhs of a case with given pattern pat. If the pattern can only match non-null values, this will assert that the selector sel is not null in these regions.

Create a nullable type bound If lo is Null, | Null is added to hi

Create a nullable type bound tree If lo is Null, | Null is added to hi

Is the given reference tracked for nullability?

This is the case if one of the following holds:

1. The reference is a path to an immutable val.
2. The reference is to a mutable variable, in which case all assignments to it must be reachable (in the sense of how it is defined in assignmentSpans) and the variable must not be used "out of order" (in the sense specified by usedOutOfOrder).

Whether to track a local mutable variable during flow typing? We track a local mutable variable iff the variable is not assigned in a closure. For example, in the following code x is assigned to by the closure y, so we do not do flow typing on x.

var x: String|Null = ???
def y = {
  x = null
}
if (x != null) {
  // y can be called here, which break the fact
  val a: String = x // error: x is captured and mutated by the closure, not trackable
}

Check usedOutOfOrder to see the explaination and example of "out of order". See more examples in tests/explicit-nulls/neg/var-ref-in-closure.scala.

Post process all arguments to by-name parameters by removing any not-null info that was used when typing them. Concretely: If an argument corresponds to a call-by-name parameter, drop all embedded not-null assertions of the form x.$asInstanceOf[x.type & T] where x is a reference to a mutable variable. If the argument still typechecks with the removed assertions and is still compatible with the formal parameter, keep it. Otherwise issue an error that the call-by-name argument was typed using flow assumptions about mutable variables and suggest that it is enclosed in a byName(...) call instead.

The initial context to be used for a while expression with given span. In this context, all variables that are assigned within the while expression have their nullability status retracted, i.e. are not known to be not null. While necessary for soundness, this scheme loses precision: Even if the initial state of the variable is not null and all assignments to the variable in the while expression are also known to be not null, the variable is still assumed to be potentially null. The loss of precision is unavoidable during normal typing, since we can only do a linear traversal which does not allow a fixpoint computation. But it could be mitigated as follows:

• initially, use whileContext as computed here
• when typechecking the while, delay all errors due to a variable being potentially null
• afterwards, if there are such delayed errors, run the analysis again with as a fixpoint computation, reporting all previously delayed errors that remain.

The following code would produce an error in the current analysis, but not in the refined analysis:

class Links(val elem: T, val next: Links | Null)

var xs: Links | Null = Links(1, null) var ys: Links | Null = xs while xs != null ys = Links(xs.elem, ys.next) // error in unrefined: ys is potentially null here xs = xs.next