CFE sometimes fails to promote to non-nullable based on null checks in guards

[stereotype441]

When running under the VM, the following constructs fail to promote:

var _ = switch (...) {
  int? y when y != null => ... // `y` is not promoted here
  ...
};
if (... case int? y when y != null) {
  // `y` is not promoted here
}
var _ = [if (... case int? y when y != null) ... // `y` is not promoted here
    ]; // And similar for sets and maps

However, trying to do the same thing with a switch statement does promote:

switch (...) {
  case int? y when y != null:
    // `y` is promoted to `int` here
}

This doesn't happen when running the CFE by itself (e.g. when testing in cfe-strong-linux mode). But it does happen if the program is run under the VM.

The analyzer properly promotes in all these circumstances.

I'm working on a fix.

[stereotype441]

This is happening because of inconsistencies in the CFE and the _fe_analyzer_shared logic about whether the expressions passed to flow analysis should be pre-lowered expressions or lowered expressions. The CFE logic for handling forms like y != null lowers the expression to !(y == null) when compiling for the VM, and uses the convention of passing the lowered expression to flow analysis. The shared logic for switch statements re-reads the guard expression after visiting it (picking up the lowered expression), and uses it in further calls to flow analysis. So it's effectively using the same convention. This is why the promotion works in switch statements. However, the shared logic for switch expressions, if-case statements, and if-case elements doesn't re-read the guard expression after visiting it, so effectively it's using the convention of passing the pre-lowered expression to flow analysis; as a result, promotion doesn't work.

I'm currently working on a fix that changes the shared logic to uniformly use convention of passing the pre-lowered expression to flow analysis, and adds a call to FlowAnalysis.forwardExpression to sync up the conventions when necessary. That should fix this issue in the short term. In the long term, I plan to fix the issue for good by switching everything over to using pre-lowered expressions (see #52189).