Note that ed38577 simply deletes and regenerates the baseline in order to make comparison easier in the subsequent commit.

I decided to do this bit first, as the precise method of doing it had been in my head. There are corresponding nullable analysis changes I'd like to make, but nullable does more complex things with conditional expressions. Therefore I'd like to do those changes in a subsequent PR.

/cc @jcouv

Implementation of part of dotnet/csharplang#4472. The relevant spec sections implemented in this PR are:

Boolean constant expressions

We introduce a new section "Boolean constant expressions":

For an expression expr where expr is a constant expression with a bool value:

• The definite assignment state of v after expr is determined by:
  • If expr is a constant expression with value true, and the state of v before expr is "not definitely assigned", then the state of v after expr is "definitely assigned when false".
  • If expr is a constant expression with value false, and the state of v before expr is "not definitely assigned", then the state of v after expr is "definitely assigned when true".

Remarks

We assume that if an expression has a constant value bool false, for example, it's impossible to reach any branch that requires the expression to return true. Therefore variables are assumed to be definitely assigned in such branches. This ends up combining nicely with the spec changes for expressions like ?? and ?: and enabling a lot of useful scenarios.

It's also worth noting that we never expect to be in a conditional state before visiting a constant expression. That's why we do not account for scenarios such as "expr is a constant expression with value true, and the state of v before expr is "definitely assigned when true".

?: (conditional) expressions

We augment the section ?: (conditional) expressions as follows:

For an expression expr of the form expr_cond ? expr_true : expr_false:

• ...
• The definite assignment state of v after expr is determined by:
  • ...
  • If the state of v after expr_true is "definitely assigned when true", and the state of v after expr_false is "definitely assigned when true", then the state of v after expr is "definitely assigned when true".
  • If the state of v after expr_true is "definitely assigned when false", and the state of v after expr_false is "definitely assigned when false", then the state of v after expr is "definitely assigned when false".

Remarks

This makes it so when both arms of a conditional expression result in a conditional state, we join the corresponding conditional states and propagate it out instead of unsplitting the state and allowing the final state to be non-conditional. This enables scenarios like the following:

bool b = true;
object x = null;
int y;
if (b ? x != null && Set(out y) : x != null && Set(out y))
{
  y.ToString();
}

bool Set(out int x) { x = 0; return true; }

This is an admittedly niche scenario, that compiles without error in the native compiler, but was broken in Roslyn in order to match the specification at the time. See internal issue.

Relates to test plan #51463