NullReferenceException in AbstractFlowPass evaluating local function with switch statement in EE

[cston]

Break in C# code and evaluate the following expression in the EE:

new Action<int>(x =>
{
    int F(int y)
    {
        switch (y)
        {
            case > 0: return 1;
            case < 0: return -1;
            case 0: return 0;
            default: return 0;
        }
    }
    F(x);
}).Invoke(1)

Result: NullReferenceException in AbstractFlowPass<,>.IsTraditionalSwitch() since compilation == null.

Microsoft.CodeAnalysis.CSharp.dll!Microsoft.CodeAnalysis.CSharp.AbstractFlowPass<Microsoft.CodeAnalysis.CSharp.ControlFlowPass.LocalState, Microsoft.CodeAnalysis.CSharp.ControlFlowPass.LocalFunctionState>.IsTraditionalSwitch(Microsoft.CodeAnalysis.CSharp.BoundSwitchStatement node) Line 96 C#
...
Microsoft.CodeAnalysis.CSharp.dll!Microsoft.CodeAnalysis.CSharp.Binder.BindLocalFunctionStatement.__runAnalysis|872_0(Microsoft.CodeAnalysis.CSharp.BoundBlock block, Microsoft.CodeAnalysis.CSharp.BindingDiagnosticBag blockDiagnostics, ref Microsoft.CodeAnalysis.CSharp.Binder.<>c__DisplayClass872_0 value) Line 605 C#
...

[jinujoseph]

cc @tmat

[jcouv]

From discussion with @AlekseyTs and @cston, the EE is constructing a binding environment using PE symbols which causes source symbols to be parented to PE symbols, and that breaks some compiler assumptions.
We would rather not take compiler-side workarounds (such as making DeclaringCompilation property resilient to this situation).

Instead, we would rather wait a bit and spend a few days to a week investigating a more systematic EE-side solution. In broad strokes, we would cook up a new method symbol and new containing type (parented to a source module, implementing a non-null DeclaringCompilation) and use those in the binding chain that the EE constructs.