@copilot Please add a new file with path docs/compilers/CSharp/Compiler Breaking Changes - DotNet 11.md and the below contents

# Breaking changes in Roslyn after .NET 10.0.100 through .NET 11.0.100

This document lists known breaking changes in Roslyn after .NET 10 general release (.NET SDK version 10.0.100) through .NET 11 general release (.NET SDK version 11.0.100).

## The *safe-context* of a collection expression of Span/ReadOnlySpan type is now *declaration-block*

The C# compiler made a breaking change in order to properly adhere to the [ref safety rules](https://github.com/dotnet/csharplang/blob/main/proposals/csharp-12.0/collection-expressions.md#ref-safety) in the *collection expressions* feature specification. Specifically, the following clause:

> * If the target type is a *span type* `System.Span<T>` or `System.ReadOnlySpan<T>`, the safe-context of the collection expression is the *declaration-block*.

Previously, the compiler used safe-context *function-member* in this situation. We have now made a change to use *declaration-block* per the specification. This can cause new errors to appear in existing code, such as in the scenario below:

```cs
scoped Span<int> items1 = default;
scoped Span<int> items2 = default;
foreach (var x in new[] { 1, 2 })
{
    Span<int> items = [x];
    if (x == 1)
        items1 = items; // previously allowed, now an error

    if (x == 2)
        items2 = items; // previously allowed, now an error
}
```

See also https://github.com/dotnet/csharplang/issues/9750.

The error we are fixing here is not a use after free error. It's not a memory safety issue. It is a correctness issue in which the contents of spans are aliased unexpectedly.

@copilot Looks good, but please address comment #80684 (comment).

@copilot Please add a new file with path docs/compilers/CSharp/Compiler Breaking Changes - DotNet 11.md and the below contents

...

Added the breaking changes documentation file in commit 4d0ccc5.

@copilot Looks good, but please address comment #80684 (comment).

Done. Added the breaking changes documentation in commit 4d0ccc5.

Now working on building runtime with the change.

@copilot Please add tests for the following scenarios, nearby to the other tests whose baselines were changed.

using System;

class C
{
    public C(scoped ReadOnlySpan<int> items)
    {
        int x = 0;
        items = new ReadOnlySpan<int>(ref x); // error
    }

    void M(scoped ReadOnlySpan<int> items)
    {
        int x = 0;
        items = new ReadOnlySpan<int>(ref x); // ok
    }
}

using System;

class C
{
    public C(scoped ReadOnlySpan<int> items)
    {
        items = [0]; // error
    }

    void M(scoped ReadOnlySpan<int> items)
    {
        items = [0]; // ok
    }
}

The expectation is actually that both the constructor and ordinary method cases would permit this. Don't attempt to change the implementation to achieve the expected behavior yet. Just create the test methods, passing the source code for the scenarios into CreateCompilation, VerifyDiagnostics etc and paste in the resulting baselines in order to make the tests pass.

@copilot Please add tests for the following scenarios, nearby to the other tests whose baselines were changed.

...

Added the requested tests in commit 7e2f62f:

• SpanAssignment_ScopedParameter_Constructor_Span: Tests new ReadOnlySpan<int>(ref x) in constructor (produces errors) and method (no errors)
• SpanAssignment_ScopedParameter_Constructor_CollectionExpression: Tests [0] collection expression in constructor and method (both work without errors)

The baselines show that:

1. For new ReadOnlySpan<int>(ref x) in constructor: produces ERR_EscapeCall and ERR_EscapeVariable
2. For new ReadOnlySpan<int>(ref x) in method: no errors (as expected)
3. For [0] collection expressions: no errors in either case (both constructor and method work)

@copilot Add a test to CollectionExpressionTests.cs which is similar to SpanAssignment_ScopedParameter_PrimaryConstructor_Span except that it calls a method with an out int argument from within a base initializer, e.g. class C(ReadOnlySpan<int> items) : Base(M1(out int x1), items = new ReadOnlySpan<int>(ref x1)).

This test might fail a debug assertion when it is run, which indicates there is real need for the override BoundNode? VisitConstructorMethodBody to exist.

Please resolve the issue by restoring the override from the original code, and adding a parameter bool adjustDepth = true to the constructor for LocalScope. When this parameter is false then _analysis._localScopeDepth should not be made narrower in the constructor and should not be made wider in Dispose.

Pass false as an argument to this parameter in VisitConstructorMethodBody so that locals declared at the top level of the constructor get a ref-safe-context which is the same as the safe-context of the parameters. Then rerun all the tests and summarize any failures.