Alternative fix for RuntimeHelpers.GetSubArray AOT compatibility warning

[jkotas]

C# LDM would like to keep the original "virtual" RuntimeHelpers.GetSubArray behavior.

Fixes dotnet/roslyn#69053

[ghost]

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

Issue Details

---

C# LDM would like to keep the original "virtual" RuntimeHelpers.GetSubArray behavior.

Fixes dotnet/roslyn#69053

Author:	jkotas
Assignees:	jkotas
Labels:	area-System.Runtime.CompilerServices
Milestone:	-

[ghost]

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

[jkotas]

@jcouv Here is revert of dotnet/roslyn#69053 (comment) .

I think we will need to file a breaking notice for this change. This can both:

• Change the behavior of complex pattern matching expression
• Break code that expects the array slicing to return the "non-virtual" type. For example:

test(new string[10]);

static object test(object[] a)
{
    var b = a[1..2];
    b[0] = new object();
    return b;
}

I will need your help with providing the justification.

[stephentoub]

I think we will need to file a breaking notice for this change.

This was introduced in .NET 7, right? Should we consider backporting it to .NET 8 asap, such that effectively it would only impact folks that were on .NET 7 or early .NET 8 adopters?

[jkotas]

This was introduced in .NET 7, right?

Right.

Should we consider backporting it to .NET 8 asap, such that effectively it would only impact folks that were on .NET 7 or early .NET 8 adopters?

It is a corner case and fixing it is a potential breaking change. We have lived with the current behavior for 1.5 years. I do not think that backporting this change meets the servicing bar.