[9.0-preview.1] Request Delegate Generator emits nullable annotations when Nullable Reference Types not enabled

[martincostello]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

If an application does not use nullable reference types but does use the request delegate generator, the application fails to compile due to RDG emitting code with nullable annotations.

Expected Behavior

RDG does not emit nullable annotations if the project does not use nullable reference types.

Steps To Reproduce

• Clone the martincostello/SignInWithAppleSample repository.
• Checkout the martincostello/SignInWithAppleSample@4c6ea88 commit.
• Run dotnet build from the root of the repository.

Exceptions (if any)

Example error:

❯ dotnet build
MSBuild version 17.10.0-preview-24101-01+07fd5d51f for .NET
Restore complete (1.0s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  SignInWithApple failed with errors (1.3s)
    C:\Coding\martincostello\SignInWithAppleSample\src\SignInWithApple\Microsoft.AspNetCore.Http.RequestDelegateGenerator\Microsoft.AspNetCore.Http.RequestDelegateGenerator.RequestDelegateGenerator\GeneratedRouteBuilderExtensions.g.cs(281,32): error CS8669: The annotation for nullable reference types should only be used in code within a '#nullable' annotations context. Auto-generated code requires an explicit '#nullable' directive in source. [C:\Coding\martincostello\SignInWithAppleSample\src\SignInWithApple\SignInWithApple.csproj]

.NET Version

9.0.100-preview.1.24101.2

Anything else?

No response

[captainsafia]

@martincostello Thanks for reporting this issue!

RDG enables the nullability context for generated files by adding #nullable enable in the file preamble. From my understanding, all source generated code needs to enable this since generated files don't implicitly carry the nullability context of the project.

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
#nullable enable

There's definitely something going on here since I'm able to repro the issue but I think the generator is emitting the right code here.

[captainsafia]

@chsienki Was just taking a look at this issue again. Any thoughts on why we might be seeing this even with nullability enabled via the pragma in generated source files?

The exact repro is in the commit above. Here is what the generated code looks like.

[chsienki]

@captainsafia Ignore that last comment.

It's this line that's causing the issue:

           var jsonBodyOrServiceTypeTuples = new (bool, Type)[] {
               #nullable disable
               (false, typeof(global::Microsoft.AspNetCore.Antiforgery.IAntiforgery)),
               #nullable restore
           };

The #nullable restore is resetting the context back to 'off', so everything below it is in a non-enabled context. Given that the generators owns the code below the line you should just change it to a #nullable enable to get the correct context back.

[RikkiGibson]

Chris beat me to it :)

[chsienki]

As an aside if this (false, typeof(global::Microsoft.AspNetCore.Antiforgery.IAntiforgery)), is user code then the disable should be a restore so that it matches the context it was written for.

[captainsafia]

@chsienki Oof! Good spot. Thanks.

@martincostello I should be able to fix this.