This implementation is the same shape as VisitCatchBlockWithAnyTransferFunction.

https://github.com/dotnet/roslyn/blob/c12c1dd499a928d95114b55f06cd78c40552e39f/src/Compilers/CSharp/Portable/FlowAnalysis/AbstractFlowPass.cs#L1793-L1815

The theory here is that in some dataflow analyses such as DataFlowsOut, we may "flip" the behavior of definite assignment within the /*bind*/ region, so that assigning a variable really behaves as if you "unassigned" the variable. Inside this function, we can take any "unassignments" which occurred in the RHS and propagate them to both this.State and stateWhenNotNull.

We do this by taking the "bottom" state in which all variables are assigned, and keeping it "on the side" in NonMonotonicState when we visit the right operand. After the visit, the only "unassigned" variables in the NonMonotonicState were those unassigned by the right operand, and we can simply Join those unassignments into the stateWhenNotNull.

See CondAccess_Equals_DataFlowsOut_02 for a test case which is impacted by this change.

This is the test case where behavior is affected by the implementation change. Without the change, we don't include x in the DataFlowsOut set in this scenario.

c

Why is c considered written anywhere in this function? #Closed

It appears that this is how parameters are handled in general. For example, the following test will pass in the main branch:

        [Fact]
        public void Test1()
        {
            var results = CompileAndAnalyzeDataFlowExpression(@"
class C
{
    static void M(int i)
    {
        System.Console.Write(/*<bind>*/i/*</bind>*/);
    }
}
");
            Assert.Equal("i", GetSymbolNamesJoined(results.WrittenOutside));
        }

My speculation is that it might be useful to model a parameter as having been "written" at the beginning of a method.

Consider asserting these conditions. #Closed

I found it prohibitively cumbersome to assert on this meaningfully, so I ended up deciding to just inline the local function at its call site.