Is it possible opt out of the First-Class Span Types feature?

[koszeggy]

If I'm not mistaken, the First-Class Span Types feature is the culprit of a breaking change in my unit tests, causing a nasty NullReferenceException by silently redirecting my original System.Linq.Enumerable.SequenceEqual<T>(IEnumerable<T>, IEnumerable<T>) call to System.MemoryExtensions.SequenceEqual<T>(ReadOnlySpan<T>, ReadOnlySpanT>), which has a buggy implementation in the external package version.

I already refactored my code using some C# 14.0 features (e.g. unbound generic types), so I can't downgrade the LangVersion anymore (and I don't want to lock in C# 13.0). So the question is in the title: is there a way to opt out of this feature only, while keeping the others? I scanned through the feature spec as well, but I didn't find mentioning any csproj/app switch/config option.

Disclaimer:

• I do NOT reference the buggy package, the reference is coming indirectly by NUnit3TestAdapter
• I know that a fix has been merged two weeks ago, but as of today, the latest package is 8 months old, which contains the bug, so I cannot even directly add a fixed reference to my test project.
• I know that I can use workarounds (e.g. casting the parameters to IEnumerable<T> or calling the extension method by its static class directly), and this is how I quick-fixed the test now. I would just feel safer if I could be sure that the code does not contain such silent evil redirections, hence the question.

[333fred]

No, there is no way to opt out of language features.

[koszeggy]

And isn't this a potential security (or at least stability) issue? From now on, it's very easy to break existing codes by such accidents. It's enough if a package (even an indirectly referenced one) contains an extension for a [ReadOnly]Span that hijacks an existing extension method call, originally invoking a Linq member with an array instance.

In this particular case the extension is in the System namespace, which is almost always used in every .cs file.

I would say it should be at least considered to make this feature optional, preferably disabled by default. And/or the Microsoft.CodeAnalysis.NetAnalyzers should contain an options to trigger some "Possibly unintentional method call" for which I could configure a warning severity, and suppress it one by one after a review.

[jjonescz]

It's enough if a package (even an indirectly referenced one) contains an extension for a [ReadOnly]Span that hijacks an existing extension method call, originally invoking a Linq member with an array instance.

The first-class Span feature changed nothing here, it has been possible to "hijack" your calls via extension methods since extension methods were first introduced.

[koszeggy]

The first-class Span feature changed nothing here, it has been possible to "hijack" your calls via extension methods since extension methods were first introduced.

Actually it changed very much from my POV. Due to the closeness/betterness rule such thing was possible only if you specified an extension method with a closer type to the actual one. But from now on this is kind of broken due to an extra step with the implicit conversion to a span. An array is an IEnumerable and is only convertible to a span, still, due to the new betterness rule, now the span overload is picked also for arrays.

Btw. since then I discovered an another, even more serious broken scenario: from a partially trusted domain (.NET Framework only), a similar implicit conversion to a span causes 'System.Security.VerificationException' in System.Memory.dll: Operation could destabilize the runtime in ReadOnlySpan`1.op_Implicit(T[] array). I consider it more serious because it is independent from the bug mentioned in the OP, and this will not be fixed by a new System.Memory package.

So again: could you please at least consider making this feature optional, or introduce a new rule in the .NET Analyzers, at least when a project targets the .NET Framework as well?

[jjonescz]

I'm sorry this break is affecting you, but it seems all this comes down to is the runtime bug and an unsupported scenario - i.e., it doesn't look like changing the language is the right solution.

from a partially trusted domain (.NET Framework only)

.NET Framework is not officially supported with recent C# versions, including C# 14.

could you please at least consider making this feature optional

I don't think that will happen, the language design team never wants to create dialects of the language (one big exception was nullability).

or introduce a new rule in the .NET Analyzers, at least when a project targets the .NET Framework as well?

I believe analyzers live in the dotnet/sdk repo, you can consider filing an issue there; and contributions are also welcome.

[koszeggy]

I believe analyzers live in the dotnet/sdk repo, you can consider filing an issue there

Thanks for the tip, I filed an issue: dotnet/sdk#51904

[jnm2]

Another potentially more appealing fix is to insert .AsEnumerable() before .SequenceEqual. I created a (closed-source) analyzer and code fix to catch it any time a span-based method is called inside an IQueryable context and to suggest .AsEnumerable() as the fix when that fix is possible.

[koszeggy]

Could you please share this analyzer? Only if it's public, of course.

[jnm2]

It's closed-source as I mentioned, but I'm able to share the analyzer itself:

[DiagnosticAnalyzer(LanguageNames.CSharp)]
public sealed class EntityFrameworkAnalyzer : DiagnosticAnalyzer
{
    public override ImmutableArray<DiagnosticDescriptor> SupportedDiagnostics { get; } = [DiagnosticDescriptors.UnsupportedEntityFramework6Operation];

    public override void Initialize(AnalysisContext context)
    {
        context.ConfigureGeneratedCodeAnalysis(GeneratedCodeAnalysisFlags.Analyze | GeneratedCodeAnalysisFlags.ReportDiagnostics);
        context.EnableConcurrentExecution();

        context.RegisterCompilationStartAction(context =>
        {
            if (context.Compilation.ReferencedAssemblyNames.Any(n => n.Name == "EntityFramework"))
                context.RegisterOperationAction(AnalyzeOperation, OperationKind.Invocation);
        });
    }

    private static void AnalyzeOperation(OperationAnalysisContext context)
    {
        var operation = (IInvocationOperation)context.Operation;
        if (operation.TargetMethod.Parameters.Any(p => p.Type.IsRefLikeType))
        {
            if (!OperationFacts.IsInsideExpressionTree(context.Operation))
                return;

            context.ReportDiagnostic(Diagnostic.Create(
                DiagnosticDescriptors.UnsupportedEntityFramework6Operation,
                operation.Syntax switch
                {
                    InvocationExpressionSyntax { Expression: MemberAccessExpressionSyntax memberAccess } when OperationFacts.IsInvokedAsExtensionMethod(operation)
                        => memberAccess.Name.GetLocation(),
                    InvocationExpressionSyntax invocation
                        => invocation.Expression.GetLocation(),
                    _  => operation.Syntax.GetLocation(),
                },
                "'" + operation.TargetMethod.OriginalDefinition.ToMinimalDisplayString(operation.SemanticModel!, operation.Syntax.SpanStart) + "'"));
        }
    }
}

internal static class OperationFacts
{
    public static bool IsInsideExpressionTree(IOperation operation)
    {
        return operation.Ancestors()
            .Select(ancestor => (ancestor as IAnonymousFunctionOperation)?.Parent as IConversionOperation)
            .FirstOrDefault(functionConversion => functionConversion is not null) is
            {
                Type: { OriginalDefinition: { } anonymousFunctionType },
            }
            && WellKnownSymbols.IsSystemLinqExpressionsExpression(anonymousFunctionType);
    }
}

[jnm2]

The code fix (uses some closed source helpers, but can be adapted):

[ExportCodeFixProvider(LanguageNames.CSharp), Shared]
public sealed class EntityFrameworkCodeFixProvider : CodeFixProvider
{
    public override ImmutableArray<string> FixableDiagnosticIds { get; } = [
        DiagnosticDescriptors.UnsupportedEntityFramework6Operation.Id];

    public override FixAllProvider GetFixAllProvider() => WellKnownFixAllProviders.BatchFixer;

    public override async Task RegisterCodeFixesAsync(CodeFixContext context)
    {
        var syntaxRoot = await context.Document.GetSyntaxRootAsync(context.CancellationToken);
        if (syntaxRoot is null) return;
        var semanticModel = await context.Document.GetSemanticModelAsync(context.CancellationToken);
        if (semanticModel is null) return;

        foreach (var diagnostic in context.Diagnostics)
        {
            var invocationExpression = syntaxRoot.FindNode(diagnostic.Location.SourceSpan).FirstAncestorOrSelf<InvocationExpressionSyntax>();
            if (invocationExpression is not { Expression: MemberAccessExpressionSyntax methodAccess })
                continue;

            var isInvokedAsStaticMethod = semanticModel.GetSymbolInfo(methodAccess.Expression, context.CancellationToken).Symbol is ITypeSymbol;

            var receiverExpression = isInvokedAsStaticMethod
                ? invocationExpression.ArgumentList.Arguments.FirstOrDefault()?.Expression
                : methodAccess.Expression;

            if (receiverExpression is not null && semanticModel.GetTypeInfo(receiverExpression, context.CancellationToken).Type is { TypeKind: TypeKind.Array })
            {
                var enumerableExtensionMethodResults = semanticModel.GetSpeculativeSymbolInfo(
                    invocationExpression.SpanStart,
                    BuildAsEnumerableMethodAccess(methodAccess, receiverExpression),
                    SpeculativeBindingOption.BindAsExpression);

                var anyResult = enumerableExtensionMethodResults.Symbol ?? enumerableExtensionMethodResults.CandidateSymbols.FirstOrDefault();
                if (anyResult is not null)
                {
                    var resultName = anyResult.ToMinimalDisplayString(
                        semanticModel,
                        invocationExpression.SpanStart,
                        new SymbolDisplayFormat(
                            typeQualificationStyle: SymbolDisplayTypeQualificationStyle.NameAndContainingTypesAndNamespaces,
                            memberOptions: SymbolDisplayMemberOptions.IncludeContainingType,
                            extensionMethodStyle: SymbolDisplayExtensionMethodStyle.StaticMethod));

                    if (!isInvokedAsStaticMethod)
                    {
                        context.RegisterCodeFix(
                            diagnostic,
                            $"Insert '.AsEnumerable()' to access '{resultName}'",
                            methodAccess,
                            static (syntaxRoot, methodAccess) => syntaxRoot.ReplaceNode(methodAccess, BuildAsEnumerableMethodAccess(methodAccess, receiver: methodAccess.Expression)));
                    }
                    else
                    {
                        context.RegisterCodeFix(
                            diagnostic,
                            $"Use '{resultName}'",
                            state: (
                                MethodAccessReference: methodAccess.GetReference(),
                                ContainingTypeFullName: SymbolUtils.GetFullMetadataName(anyResult.ContainingType)),
                            static async (document, state, cancellationToken) =>
                            {
                                var compilation = await document.Project.GetCompilationAsync(cancellationToken);
                                if (compilation is null) return document;

                                var containingType = compilation.GetTypeByMetadataName(state.ContainingTypeFullName);
                                if (containingType is null) return document;

                                var syntaxRoot = await document.GetSyntaxRootAsync(cancellationToken);
                                if (syntaxRoot is null) return document;

                                var syntaxGenerator = SyntaxGenerator.GetGenerator(document);
                                var generated = syntaxGenerator.TypeExpression(containingType);

                                var methodAccess = (MemberAccessExpressionSyntax)await state.MethodAccessReference.GetSyntaxAsync(cancellationToken);

                                return document.WithSyntaxRoot(syntaxRoot.ReplaceNode(methodAccess.Expression, generated));
                            });
                    }
                }
            }
        }
    }

    /// <summary>
    /// Rewrites <c>expr.SomeMethod</c> as <c>receiver.AsEnumerable().SomeMethod</c>.
    /// </summary>
    private static MemberAccessExpressionSyntax BuildAsEnumerableMethodAccess(MemberAccessExpressionSyntax methodAccess, ExpressionSyntax receiver)
    {
        return methodAccess.WithExpression(
            SyntaxFactory.InvocationExpression(
                SyntaxFactory.MemberAccessExpression(
                    SyntaxKind.SimpleMemberAccessExpression,
                    receiver,
                    SyntaxFactory.IdentifierName(nameof(Enumerable.AsEnumerable))),
                SyntaxFactory.ArgumentList()));
    }
}

[TahirAhmadov]

I've had a similar issue - the few places where I call Reverse LINQ method broke because the span Reverse extension returns void. Easy enough to fix with AsEnumerable, though.

[jjonescz]

If you use C# 14 with .NET 10 (which is the only supported configuration), this break shouldn't occur since .NET 10 defines an extension method Reverse for arrays which will have precedence over the MemoryExtensions.Reverse.

[TahirAhmadov]

@jjonescz I'm confused, VS says I have to use 17.16 to target .NET 10, but that's not available for update? The latest it's offering me is 17.14.21 (I'm on 17.14.18 now).

[yaakov-h]

@TahirAhmadov I believe you have to update to 18.0 (VS2026)

[jjonescz]

VS says I have to use 17.16 to target .NET 10

That's a bug in the error message (should be fixed in the latest 17.14 version).

I believe you have to update to 18.0 (VS2026)

That is correct. See https://learn.microsoft.com/en-us/dotnet/core/porting/versioning-sdk-msbuild-vs#lifecycle.

[TahirAhmadov]

Thank you both for the pointer.
I have to say so far I'm loving VS 2026, feels like a truly quality product. I hope the VS team knows their work is really appreciated.