[release/10.0.1xx-preview1] Update dependencies from dotnet/roslyn

[dotnet-maestro]

This pull request updates the following dependencies

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

• Subscription: dc4d990b-600a-40ce-9d08-da4830215579
• Build: 20250203.1
• Date Produced: February 3, 2025 8:58:51 PM UTC
• Commit: 001d331188b5dfa9e69b56387a8a3527e69c8a58
• Branch: refs/heads/main

• Updates:
  • Microsoft.SourceBuild.Intermediate.roslyn: from 4.14.0-1.25070.2 to 4.14.0-2.25103.1
  • Microsoft.CodeAnalysis: from 4.14.0-1.25070.2 to 4.14.0-2.25103.1
  • Microsoft.CodeAnalysis.CSharp: from 4.14.0-1.25070.2 to 4.14.0-2.25103.1
  • Microsoft.CodeAnalysis.CSharp.CodeStyle: from 4.14.0-1.25070.2 to 4.14.0-2.25103.1
  • Microsoft.CodeAnalysis.CSharp.Features: from 4.14.0-1.25070.2 to 4.14.0-2.25103.1
  • Microsoft.CodeAnalysis.CSharp.Workspaces: from 4.14.0-1.25070.2 to 4.14.0-2.25103.1
  • Microsoft.CodeAnalysis.Workspaces.Common: from 4.14.0-1.25070.2 to 4.14.0-2.25103.1
  • Microsoft.CodeAnalysis.Workspaces.MSBuild: from 4.14.0-1.25070.2 to 4.14.0-2.25103.1
  • Microsoft.Net.Compilers.Toolset: from 4.14.0-1.25070.2 to 4.14.0-2.25103.1
  • Microsoft.Net.Compilers.Toolset.Framework: from 4.14.0-1.25070.2 to 4.14.0-2.25103.1

[ViktorHofer]

Same failures as in #46195. cc @adamsitnik (System.CommandLine related?)

[adamsitnik]

Same failures as in #46195. cc @adamsitnik (System.CommandLine related?)

That is correct, it's S.CL update from dotnet/roslyn#76948. It was merged to main and I was not expecting it to be backported to P1.

[ViktorHofer]

@jaredpar this needs the revert that we talked about in Tactics.

[lewing]

Picking up the latest preview1 flow should resolve the workload failure

[ViktorHofer]

I went ahead and added a patch to revert the System.CommandLine change in the VMR to unblock the source-build leg.

[ViktorHofer]

@dotnet/source-build presumably we need this PR for Preview 1 as it brings in 250 commits from roslyn. Can you please take a look at the failures?

[mthalman]

The build error is in the stage 2 source build leg and is caused by using the latest version of the SDK to build the VMR. That has exposed some code in the razor repo that is violating some new code analysis logic introduced in that version of the SDK. Someone from razor needs to resolve these code issues. cc @davidwengier, @DustinCampbell

[DustinCampbell]

The build error is in the stage 2 source build leg and is caused by using the latest version of the SDK to build the VMR. That has exposed some code in the razor repo that is violating some new code analysis logic introduced in that version of the SDK. Someone from razor needs to resolve these code issues. cc @davidwengier, @DustinCampbell

This looks to me like a bug in the code analysis. The Razor code appears to be correct. Below is an example of the code that is being flagged. The analyzer is reporting that "keys" is not used and can be removed, but that is clearly not true. Perhaps the analyzer failed to consider assignments to element access expressions? cc @jaredpar because it seems like Roslyn is bringing in a broken analyzer.

private bool ComputeIdentityKeys<TElement>(IReadOnlyList<TElement> items, Span<SortKey<T>> keys)
{
    Debug.Assert(typeof(TElement) == typeof(T));

    var isOutOfOrder = false;
    var count = items.Count;

    var previousKey = (T)(object)items[0]!;
    keys[0] = new(Index: 0, previousKey);

    for (var i = 1; i < count; i++)
    {
        var currentKey = (T)(object)items[i]!;
        keys[i] = new(Index: i, currentKey);

        if (!isOutOfOrder)
        {
            if (!AreInSortedOrder(currentKey, previousKey))
            {
                // Continue processing to finish converting elements to keys. However, we can stop comparing keys.
                isOutOfOrder = true;
            }

            previousKey = currentKey;
        }
    }

    return !isOutOfOrder;
}

[ViktorHofer]

cc @CyrusNajmabadi

[jaredpar]

@arunchndr, @sharwell as the failure is IDE0060.

[arunchndr]

Sam is looking at it

[sharwell]

@DustinCampbell I cannot reproduce the failure in Roslyn unit tests for the affected analyzer. It also appears to not be reproduced in the normal build (just source build). Can we suppress it there until we can get an isolated repro case?

[DustinCampbell]

I'll have to defer to @jaredpar to suppress the warning. I honestly have no idea how to update the Razor compiler sources used by source build.

FWIW, thiis can be reproed with the latest Visual Studio IntPreview using the Razor repo.

1. Clone https;//github.com/dotnet/razor
2. Restore.cmd
3. Open Razor.sln in Visual Studio.
4. Open SortHelper`1.cs.

The same warnings reported in this PR appear in the editor:

[jaredpar]

I'll have to defer to @jaredpar to suppress the warning.

I don't have concerns with suppressing it here as a mechanism to get code flow working again. But I want to make sure we're following up in the IDE to understand what is happening here. Cause this seems to be a regression of some sorts and want to sort it out before it hits customers.

@sharwell, @arunchndr do we have a tracking issue on IDE that we can reference in the suppression?

[marcpopMSFT]

darc created a separate PR #46518 but all the conversation is here.

[ViktorHofer]

This one didn't make it in time for P1. Let's continue the discussion in #46546 (main).

[nagilson]

This did not make it in time.