When collecting local properties for property initialization analysis,
the nodes of the CFG were navigated. However, there are problems when
trying to determine what local properties are defined within do-while
loops. This is because the node order of a CFG does not always follow
the FIR structure order.
By converting the collector to a FIR visitor, we can maintain the
structural order needed for finding properties defined within do-while
loops. This does require some additional logic though to make sure we
do not navigate into elements which are not part of the original graph
navigation.
^KT-65911 Fixed
Local properties defined within the body of a do-while loop can be used
in the condition of the loop. However, use of a `continue` may mean the
property isn't always initialized, even if it is initialized when it is
defined. So while a local property may be within scope and has an
initializer, this doesn't always mean that the property is initialized.
As such, properties that are defined within a do-while loop and also
used in the condition of the same do-while loop should be tracked. Then,
these properties should still be checked for proper initialization even
if they have an initializer.
^KT-64872 Fixed
Parameters/vals with an immediate initializer (which we assume is a
rather common situation) do not require any kind of complicated CFA
- Unused vals can be simply determined by linear traversal of
the pseudocode
- Definite assignment is a bit more complicated: a read-instruction of val
can be considered as a safe if it's located *after* the first write in
the pseudocode. It works almost always beside the case with do/while
(see the test changed). This case will be fixed in the further commits
The test for kt897.kt will also be fixed further, all other changes
might be considered as minor as they mostly change diagnostics for
already red code
Brian Norman