Using new C# 9.0 language feature causes the performance CI tests to fail

[steveharter]

When trying to use the new C# 9.0 'record' usage in tests the dotnet-runtime-perf leg failed with:
Serialization\ConstructorTests\ConstructorTests.Exceptions.cs(156,37): error CS0518: (NETCORE_ENGINEERING_TELEMETRY=Build) Predefined type 'System.Runtime.CompilerServices.IsExternalInit' is not defined or imported

The test csproj did need to add <LangVersion>preview</LangVersion>, which seemed to work fine execpt for the performance leg:

#38959 (comment)

[ghost]

Tagging subscribers to this area: @safern, @ViktorHofer
Notify danmosemsft if you want to be subscribed.

[stephentoub]

cc: @DrewScoggins

[DrewScoggins]

I will take a look at this.

[DrewScoggins]

Is the link to the PR above the one where you are seeing the failure? Because when I look at that all of the CI is green.

EDIT: I see, that was taken out of the PR.

[DrewScoggins]

So I investigated this and what happened was that the AzDO controller somehow got disconnected from tracking the Helix work items. You can see that in the failure on AzDO here, https://dev.azure.com/dnceng/public/_build/results?buildId=721665&view=logs&j=319274cb-4008-5c3f-98b0-4b6b2825e9cf. So I dug into the Kusto logs of Helix and for both of the "failed" jobs all of the workitems completed correctly. So there is no problem here, you can just add back that record type and I doubt it will cause an issue. This failure just seems like a transient issue in AzDO.

[safern]

Yeah, I'm seeing the same behavior as @DrewScoggins. @steveharter if you don't want to block your PR on CI, could you merge and put up another PR to re-enable this and see if we can get a repro or if it was just an unrelated transient issue.

[steveharter]

I'll re-add the record type and ping you two if there's an issue. Thanks

[steveharter]

There is still an issue: #38959 (comment)

[steveharter]

@jaredpar is this issue a duplicate of dotnet/roslyn#45510?

[safern]

@jaredpar are there any plans on supporting the record type downlevel?

[jaredpar]

@steveharter

Essentially yes it's a dupe

@safern

The issue here isn't so much downlevel support as we're missing a type required for code geneartion of the feature. The type is just a marker type (used for some modreq). If the down level frameworks have this type defined then the compiler can emit record types properly.

Going back in time it's very similar to extension methods. The type necessary to emit extension methods, ExtensionAttribute, was added in .NET 3.5. It was still possible to use them in 2.0 though, u just had to define the type yourself in the code.

[safern]

I see.

@steveharter if you wanted those tests to work, then we can just define the type on the test project for net472 then, right?

[steveharter]

then we can just define the type on the test project for net472 then, right?

Yes essentially. Currently I just have an #if but could have moved the tests to a separate .cs file along with a conditional include in the csproj. The latter approach would be best if this is going to be a long-term issue.

[safern]

It seems like that is how it is going to be based on:

The issue here isn't so much downlevel support as we're missing a type required for code geneartion of the feature. The type is just a marker type (used for some modreq). If the down level frameworks have this type defined then the compiler can emit record types properly.
Going back in time it's very similar to extension methods. The type necessary to emit extension methods, ExtensionAttribute, was added in .NET 3.5. It was still possible to use them in 2.0 though, u just had to define the type yourself in the code.

[safern]

@steveharter maybe we should either close this issue or fix it as suggested above. Up to you what direction we want to go here.

[steveharter]

So I should add this type to the test project for #if !NETCOREAPP:

namespace System.Runtime.CompilerServices
{
    public sealed class IsExternalInit
    {
    }
}

?

[safern]

Yeah, I think so. We should just put it in a separate file though and conditionally include it to the Compile items based on the TFM.