[main] Update dependencies from dotnet/roslyn

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/roslyn

• Subscription: 037eb78c-9902-4cb9-856d-08db8ed7cafd
• Build:
• Date Produced: March 25, 2024 11:41:10 AM UTC
• Commit: 919d4dbfb0dffb35a702417e28ceea652d248bc6
• Branch: refs/heads/main

• Updates:
  • Microsoft.SourceBuild.Intermediate.roslyn: from 4.10.0-2.24114.13 to 4.10.0-3.24175.2
  • Microsoft.CodeAnalysis: from 4.10.0-2.24114.13 to 4.10.0-3.24175.2
  • Microsoft.CodeAnalysis.CSharp: from 4.10.0-2.24114.13 to 4.10.0-3.24175.2
  • Microsoft.Net.Compilers.Toolset: from 4.10.0-2.24114.13 to 4.10.0-3.24175.2

[jkotas]

@jaredpar Roslyn update introduced a build break in a very old dynamic test:

src/libraries/System.Runtime/tests/System.Dynamic.Runtime.Tests/Dynamic.Context/Conformance.dynamic.context.operator.regclass.cs(4383,29): error CS0039: (NETCORE_ENGINEERING_TELEMETRY=Build) Cannot convert type 'void' to 'object' via a reference conversion, boxing conversion, unboxing conversion, wrapping conversion, or null type conversion

[stephentoub]

I think @chsienki was looking into it in #98559

[jjonescz]

Roslyn update introduced a build break in a very old dynamic test

class C
{
    static object M1()
    {
        var a = "";
        dynamic da = a;
        return M2(da) as object;
    }

    static void M2(string s) { }
}

This scenario behaves differently after Params Collections - Adjust binding in presence of dynamic arguments (71421). There's a new error:

// (7,16): error CS0039: Cannot convert type 'void' to 'object' via a reference conversion, boxing conversion, unboxing conversion, wrapping conversion, or null type conversion
//         return M2(da) as object;
Diagnostic(ErrorCode.ERR_NoExplicitBuiltinConv, "M2(da) as object").WithArguments("void", "object").WithLocation(7, 16)

@AlekseyTs is that expected?

[AlekseyTs]

is that expected?

I would say yes. There is only one applicable candidate. Therefore, compile time resolution is performed. Therefore, result type of the invocation is not dynamic.

[jaredpar]

@AlekseyTs can the old behavior be achieved by adding a second overload here to force the more dynamic interpretation? Example:

static void M2(int i) { }

[AlekseyTs]

can the old behavior be achieved by adding a second overload here to force the more dynamic interpretation?

Yes, https://sharplab.io/#v2:EYLgZgpghgLgrgJwgZwLQAUoKgW2QYQHsAbYiAYxgEtCA7ZAGhhCuIB8ABAJgAJ8BYAFABvIT3E8OARgBsPQsABWFGDwCyUgBQBKMRNGCJRngDcsPKDwC8PAES2A3HuM8AJgE9auKuTeWbUE6GLpIA7Opcmq5Q2hbI8koqQUYAvkLOkrKSACwRmtIADDzIscI8acHi0nIcuWqRVLSqJTxlFSlAA=

[stephentoub]

I assume this no longer compiling is also considered a bug fix?
https://sharplab.io/#v2:EYLgtghglgdgPgAQMwAIECYUGEUG8CwAUCiWqggCwoCyAFNQJ5YA2EAzmygMYCUeRpQSgAmDGBDBQuIlAF4UFANwChJLgG0kAGhEBdOQvTLipAL5FzhIsjSZGLdmyIETJG6PGTpAFwAWUNnVYbxQADx0PCSk9OQA+EWNTIA=

public class C {
    public void M(MyClass c) {
        dynamic d = 4;
        c[3, d] = 42;
    }
}

public class MyClass
{
    public dynamic this[int x, dynamic d] => d;
}

It previously compiled, but now it fails to compile with:

Property or indexer 'MyClass.this[int, dynamic]' cannot be assigned to -- it is read only

[stephentoub]

(I pushed a commit to workaround the dynamic changes to the other PR.)

[AlekseyTs]

I assume this no longer compiling is also considered a bug fix?

A language design change.

[stephentoub]

Closing in favor of #98559