Special care has to be taken when reporting dead code for `for`
statements and `for` elements, because the "updaters" part of a
for-loop appears before the body in source, but is executed after the
body. This means that if the end of the loop body is unreachable, then
a separate dead_code range might need to be generated to cover the
updaters.
Previously, this was accomplished by special-case logic in
`NullSafetyDeadCodeVerifier.flowEnd`: if the parent of
`_firstDeadNode` was a `ForStatement` (or a `Block` inside a
`ForStatement`), extra logic would be triggered to emit a dead_code
range to cover the updaters. This mostly worked, but it didn't handle
a `Block` inside a `Block` inside a `ForStatement`, and I couldn't
figure out a good way to generalize it to handle `ForElement`s.
The new approach is for the resolver to make two additional calls into
`NullSafetyDeadCodeVerifier`, just after visiting the "condition" part
of the loop and just before visiting the updaters. Combining together
information gathered at these two times, the
`NullSafetyDeadCodeVerifier` can determine whether or not it's
necessary to emit a separate dead_code range to cover the updaters.
Pre-existing tests in `dead_code_test.dart` still pass, and I've added
a bunch of tests of the new functionality.
These improvements pave the way for improvements to the analysis
server's "remove dead code" fix, which I want to do in order to
prepare for the rollout of sound flow analysis.
Bug: https://github.com/dart-lang/sdk/issues/60438
Change-Id: I6d2c43fd7c06adcd4de22d42144b033319e949a3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/424180
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Paul Berry
7303fcab25