CentOSStream9 legs failing to build CoreCLR Component

[ellahathaway]

CentOS legs are failing to build runtime in the VMR with the following error:

In file included from <built-in>:1:
      In file included from /vmr/src/runtime/artifacts/source-build/self/src/artifacts/obj/coreclr/linux.x64.Release/debug/di/CMakeFiles/cordbdi.dir/cmake_pch.hxx:5:
      In file included from /vmr/src/runtime/artifacts/source-build/self/src/src/coreclr/debug/di/stdafx.h:30:
      /vmr/src/runtime/artifacts/source-build/self/src/src/coreclr/debug/di/rspriv.h:6357:36: error: in-class initializer for static data member is not a constant expression
       6357 |     static const CorDebugUserState kInvalidUserState = CorDebugUserState(-1);
            |                                    ^                   ~~~~~~~~~~~~~~~~~~~~~
      /vmr/src/runtime/artifacts/source-build/self/src/src/coreclr/debug/di/rspriv.h:6357:56: note: integer value -1 is outside the valid range of values [0, 511] for the enumeration type 'CorDebugUserState'
       6357 |     static const CorDebugUserState kInvalidUserState = CorDebugUserState(-1);
            |                                                        ^
      1 error generated.

##[error]Failed to build "CoreCLR component".

Link to build

[ellahathaway]

It looks like this failure started occurring with dotnet/dotnet@f85781e... Nothing in that commit particularly stands out to be besides the changes to installer's NuGet.Config file (eg the removal of <add key="darc-int-dotnet-runtime-a2266c7" value="true" />)

[ellahathaway]

@MichaelSimons - any chance this could be an instance of NuGet feed non-determinism?

[MichaelSimons]

I'm not sure what the RCA is but I do see something that seems to be the cause of this....

6 months ago these two changes were made:

1. dotnet/dotnet@9457265#diff-1a87546e9f53fca80d8b27c81313cde8f7e9069af5412f4f85c85e5f5e8dfa8cR12
2. dotnet/dotnet@9457265#diff-f6311139bc123b07f84392bd32eb37be69ddb415dfddd4d59b4818e2b3ed54a9R189

The key thing to note here is that one and only one V.D.xml dependency exists - https://github.com/dotnet/dotnet/blob/release/8.0.1xx/src/runtime/eng/Version.Details.xml#L405

This means these nuget versions will be incoherent in SB which could explain the behavior seen. I think the fix is to define these all in V.D.xml or define the properties to be dependent on the Nuget.ProjectModel value.

[ellahathaway]

I feel like the NuGet issue might not be the main cause of the issue because I'm now seeing the CoreCLR error in 9.0 as well with no NuGet warnings (NuGet deps are defined in the 9.0 V.D.xml). This error only happens in CentOS legs. I updated the issue title and description to better reflect the error.

[ellahathaway]

@jkotas, can you please take a look? Thanks in advance

[jkotas]

static const CorDebugUserState kInvalidUserState = CorDebugUserState(-1);
/vmr/src/runtime/artifacts/source-build/self/src/src/coreclr/debug/di/rspriv.h:6357:56: note: integer value -1 is outside the valid range of values [0, 511] for the enumeration type 'CorDebugUserState'

This build break is caused by upgrading clang compiler in the build image. The fixes for these build breaks have been backported to all release branches:

.NET 10: dotnet/runtime#121124
.NET 9: dotnet/runtime#121151
.NET 8: dotnet/runtime#121150

You either need to make sure to pick up these fixes, or pin the build image to a version without updated clang compiler until these fixes flow everywhere.

It looks like this failure started occurring with dotnet/dotnet@f85781e... Nothing in that commit particularly stands out to be besides the changes to installer's NuGet.Config file

Yes, the build breaks introduced by floating build images out of the blue in unrelated PRs always cause a lot of confusion. It happens fairly regularly, every few months. I wish there was more predictable scheme for build image updates. dotnet/dotnet-buildtools-prereqs-docker#1371 (comment) and related issues have discussion about that.