Upgrade to .NET 7 P6 SDK

[allisonchou]

Running this through scouting queue to see if it fixes failures we're seeing

[dibarbet]

@dotnet/roslyn-compiler could I get some assistance with the compiler server errors in the correctness build?

Build FAILED.

D:\a\_work\1\s\eng\targets\Bootstrap.targets(4,5): error : Compiler request rejected [D:\a\_work\1\s\src\Compilers\Extension\Roslyn.Compilers.Extension.csproj]
D:\a\_work\1\s\artifacts\Bootstrap\tasks\net472\Microsoft.CSharp.Core.targets(79,5): error MSB6006: "csc.exe" exited with code 57005. [D:\a\_work\1\s\src\EditorFeatures\Core.Wpf\Microsoft.CodeAnalysis.EditorFeatures.Wpf_icujsfd5_wpftmp.csproj]
D:\a\_work\1\s\eng\targets\Bootstrap.targets(4,5): error : Compiler request rejected [D:\a\_work\1\s\src\Tools\ExternalAccess\Xamarin.Remote\Microsoft.CodeAnalysis.ExternalAccess.Xamarin.Remote.csproj]
    0 Warning(s)
    3 Error(s)

There's also consistent tests in CompoundAssignment.vb failing (all for Bug1021941) on all CI legs, which I plan to disable
https://sourceroslyn.io/#Microsoft.CodeAnalysis.VisualBasic.Semantic.UnitTests/Semantics/CompoundAssignment.vb,1098

[dibarbet]

@chsienki looks like the compiler server failures might be source generator related?

ID=VBCSCompiler TID=60: Begin Analyzer Consistency Check
ID=VBCSCompiler TID=60: End Analyzer Consistency Check
ID=VBCSCompiler TID=60: Begin 4e8c2ffc-cb5c-488d-94bd-113203bd60b3 Visual Basic compiler run
ID=VBCSCompiler TID=33: Debug.Assert failed with message: Fail: 
Stack Trace
   at Microsoft.CodeAnalysis.CommandLine.ExitingTraceListener.Exit(String originalMessage)
   at Microsoft.CodeAnalysis.CommandLine.ExitingTraceListener.WriteLine(String message)
   at System.Diagnostics.TraceInternal.Fail(String message)
   at System.Diagnostics.Debug.Assert(Boolean condition)
   at Microsoft.CodeAnalysis.GeneratorDriver..ctor(GeneratorDriverState state)
   at Microsoft.CodeAnalysis.CSharp.CSharpGeneratorDriver..ctor(GeneratorDriverState state)
   at Microsoft.CodeAnalysis.CSharp.CSharpGeneratorDriver.FromState(GeneratorDriverState state)
   at Microsoft.CodeAnalysis.GeneratorDriver.RunGeneratorsAndUpdateCompilation(Compilation compilation, Compilation& outputCompilation, ImmutableArray`1& diagnostics, CancellationToken cancellationToken)
   at Microsoft.CodeAnalysis.CommonCompiler.RunGenerators(Compilation input, ParseOptions parseOptions, ImmutableArray`1 generators, AnalyzerConfigOptionsProvider analyzerConfigOptionsProvider, ImmutableArray`1 additionalTexts, DiagnosticBag generatorDiagnostics)
   at Microsoft.CodeAnalysis.CommonCompiler.CompileAndEmit(TouchedFileLogger touchedFilesLogger, Compilation& compilation, ImmutableArray`1 analyzers, ImmutableArray`1 generators, ImmutableArray`1 additionalTextFiles, AnalyzerConfigSet analyzerConfigSet, ImmutableArray`1 sourceFileAnalyzerConfigOptions, ImmutableArray`1 embeddedTexts, DiagnosticBag diagnostics, CancellationToken cancellationToken, CancellationTokenSource& analyzerCts, AnalyzerDriver& analyzerDriver, Nullable`1& generatorTimingInfo)
   at Microsoft.CodeAnalysis.CommonCompiler.RunCore(TextWriter consoleOutput, ErrorLogger errorLogger, CancellationToken cancellationToken)
   at Microsoft.CodeAnalysis.CommonCompiler.Run(TextWriter consoleOutput, CancellationToken cancellationToken)
   at Microsoft.CodeAnalysis.CompilerServer.CompilerServerHost.RunCompilation(RunRequest& request, CancellationToken cancellationToken)
   at Microsoft.CodeAnalysis.CompilerServer.CompilerServerHost.Microsoft.CodeAnalysis.CompilerServer.ICompilerServerHost.RunCompilation(RunRequest& request, CancellationToken cancellationToken)
   at Microsoft.CodeAnalysis.CompilerServer.ClientConnectionHandler.<>c__DisplayClass8_0.<ProcessCompilationRequestAsync>b__1()
   at System.Threading.Tasks.Task`1.InnerInvoke()
   at System.Threading.Tasks.Task.Execute()
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)
   at System.Threading.Tasks.Task.ExecuteEntry(Boolean bPreventDoubleExecution)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart(Object obj)

[chsienki]

@dibarbet Interesting, that assert is called when we're passing the same type of generator to the driver multiple times, which usually indicates a test authoring issue. I guess some generator tests got introduced? Though I don't see how main isn't failing in that case?

[JoeRobich]

This PR updates the SDK meaning the compiler toolset is updated to whatever shipped in Preview 6. How old is this assert?

[dibarbet]

Not familiar at all with the area - could the new preview sdk be adding a duplicate generator?

Note that this is failing in the correctness build, so I don't think tests apply here?

[chsienki]

Yeah, this is very weird. Looking at the correctness builds its not failing on the same projects either, which suggests something else strange is going on.

In theory, outside of tests, you shouldn't be able to hit this assert, because the analyzer loader will only return a single type of each generator / analyzer. We have the assert (and have done so for multiple years) to check that invariant isn't being broken in tests (and thus testing something that shouldn't be possible).

Clearly that assertion is not holding for some reason, my guess being something in the analyzer loader has changed meaning we're now somehow creating multiple instances of a single type? Do we know which compiler commit we're updating from and to?

[chsienki]

Ugh, hang on, this is even more confusing. Its not at the initial construction that it's failing, but after the generators have run and we've modified the state. That suggests we're somehow incorrectly modifying the generator state. And given that its happening on different projects, that possibly its a race condition we've exposed via the new SDK.

Bleurgh. I'll keep digging.

[RikkiGibson]

It sounds like it may not be relevant, but FWIW we have seen cases where the same generator gets passed multiple times during the build and weird things happen. #62610

[jaredpar]

It sounds like it may not be relevant, but FWIW we have seen cases where the same generator gets passed multiple times during the build and weird things happen.

That was my first thought too but last night I took a look at the binlog and didn't see any generator obviously being passed twice. Possible it's more subtle than I realize but at a glance this wasn't the issue.

[dibarbet]

Per conversation with @chsienki and @vatsalyaagrawal we will be disabling the tests for CompoundAssignment.Bug1021941 which consistently fail on .net7p6 so that we can fix the scouting queue and merge the -vs-deps branches back into main.

[dibarbet]

@chsienki for review on the compiler test changes

[dibarbet]

planning on merging Monday (just sent a reminder email)

[JoeRobich]

❤️