[CP] Account for differing flow analysis conventions between CFE and shared code. #52343
Labels
area-front-end
Use area-front-end for front end / CFE / kernel format related issues.
cherry-pick-approved
Label for approved cherrypick request
cherry-pick-merged
Cherry-pick has been merged to the stable or beta branch.
cherry-pick-review
Issue that need cherry pick triage to approve
merge-to-stable
Commit(s) to merge
cb0eb28
Target
Stable
Prepared changelist for beta/stable
https://dart-review.googlesource.com/c/sdk/+/302642
Issue Description
When running in the VM, certain expressions that imply type promotions are sometimes rewritten by the compilation pipeline. If those expressions appear in certain contexts involving patterns, the rewrite could cause type promotion to be lost. This happens because of differences in flow analysis conventions between the front end and the shared implementation of patterns: the front end assumes that the rewritten expressions will be passed to flow analysis, whereas the shared logic assumes the original expressions will be passed to flow analysis.
For example, this code is accepted by the analyzer but not the VM, because the guard clause
j != null
is internally rewritten to!(j == null)
, causing the promotion ofj
to non-nullable to be lost:What is the fix
We account for the difference in conventions by adding a call to
FlowAnalysis.forwardExpression
to the front end's implementation ofdispatchExpression
. This ensures that when transitioning between front end logic and shared logic, flow analysis will be informed how to match up the rewritten expressions to their original counterparts.Why cherry-pick
This change fixes type promotion to be consistent between the analyzer and the VM. Without this fix, there could be customer frustration, because a type might appear to promote properly in the IDE, but then fail to compile when run under the VM.
The fix is confined to the new shared analysis infrastructure and the
dispatchExpression
method, which are only used for patterns and switch statements. Since switch statements didn't support any type promotion prior to Dart 3.0, this means that no user code written prior to Dart 3.0 should be affected. Also, since the change brings the VM behaviour into alignment with the analyzer, it shouldn't break any user code that is already accepted by the analyzer. So I believe the overall risk of this change is low.Risk
low
Issue link(s)
#52241, #52183
Extra Info
No response
The text was updated successfully, but these errors were encountered: