commit 7703609cc1ba12b4e675b7a543313b73704d7209
author Paul Berry <paulberry@google.com> Thu Aug 17 19:16:48 2023 +0000
committer Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> Thu Aug 17 19:16:48 2023 +0000
tree 9706a9f72e30dbe1b9e86098519b58eda4a96ca7
parent 7289baece5d304420d7962244aa792112d6f8f6f

Flow analysis: fix interaction of field promotion and try/finally.

Try/finally statements have an unusual property that needs to be
handled in a special way by flow analysis: within the `finally` block,
the `try` block might not have run to completion, but after the
try/finally statement, the `try` block is known to have run to
completion. Therefore, even though the code that follows the
try/finally statement is immediately preceded by the end of the
`finally` block, the flow states of those two control flow points
might not be the same.

Flow analysis accounts for this situation by analyzing the `finally`
block as though it started executing right after the beginning of the
`try` block, but with all variables that are written within the `try`
block demoted. Then, after it finishes analyzing the `finally` block,
it builds a fresh flow model by starting with the flow state after the
end of the `try` block, and then applying any promotions that were
performed within the `finally` block. This is accomplished by the
`FlowModel.attachFinally` method.

The following changes had to be made to make this work with field
promotion:

- If a given promotion key appears in the "after try" model but not
  the "after finally" model, it might represent a field that was
  promoted during the `try` block, so the promotion needs to be
  preserved. Previously, this situation could only occur if the
  promotion key represented a variable declared in the `try` block
  (and therefore the variable would not be accessible after the
  try/finally statement), so the promotion could be safely dropped.

- If a given promotion key appears in the "after try" model and the
  "after finally" model, but not the "before finally" model, it might
  represent a field that was promoted within both the `try` and
  `finally` blocks, so the promotions need to be combined. Previously,
  this situation could not occur, so the promotion could be safely
  dropped.

- If a given promotion key is associated with the same SSA node in the
  "before finally" and "after finally" models, but a different SSA
  node in the "after try" model, that means that the corresponding
  variable was assigned in the `try` block but not in the `finally`
  block. If any properties of the variable were promoted within the
  `finally` block, those promotions were applied to the SSA nodes used
  by the `finally` block, and don't appear in the SSA nodes used in
  the "after try" model. So those promotions need to be
  transferred. This is accomplished by the new
  `SsaNode._applyPropertyPromotions` method.

- If a given promotion key appears in the "after finally" model but
  not the "after try" model, it might represent a field that was
  promoted during the `finally` block, so the promotion needs to be
  preserved. Previously, this situation could only occur if the
  promotion key represented a variable declared in the `finally` block
  (and therefore the variable would not be accessible after the
  try/finally statement), so the promotion could be safely dropped.

Fixes https://github.com/dart-lang/sdk/issues/53225.

Bug: https://github.com/dart-lang/sdk/issues/53225
Change-Id: Ie4b635dbf838447d6964c326e1ecebfff99bed8e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320961
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>