Show where a flow-refined variable got set to a given type, which led to a type error

Flow-sensitive type refinement permits the type of a variable to change
throughout its scope, depending on the values that are assigned to it.
The type can also be changed by other factors, such as a call to an
external method that might perform arbitrary assignments.

This can mean that it is difficult for a user to determine why a particular
variable is being treated as, say, possibly-null when the user thinks that
the variable is definitely non-null.

Here is the feature request:

Whenever the Checker Framework issues a type error that involves a local
variable that is subject to flow-refinement, then the Checker Framework
should issue a second error immediately afterward, showing the line at
which the local variable was given its current type.  This will often be at
an assignment or at a method call that ends a flow-refinement scope.  There
may be multiple such locations, if dataflow has merged (say, there was an
assignment on one or more if branches); in this case, it could report
either one arbitrary location, or all locations.

This behavior is similar to what gcc does for a repeated definition:  it
issues an error for the location of the definition, then another error
saying "previous definition was here".

Original issue reported on code.google.com by michael.ernst@gmail.com on 23 Jun 2010 at 3:45

The issue names no files, tests, or entry points. Start by tracing flow-sensitive type refinement and the Checker Framework's type-error reporting, then determine how assignments, method calls, and merged branches retain source locations. Done means a relevant type error is followed by one or more diagnostics identifying where the variable acquired its current type.