dotnet format CS8618 where NUnit3002 applies

[RichardR-cg]

Describe the bug

dotnet format is fixing CS8618 inside NUnit TestFixtures where that complaint is suppressed by NUnit3002. I would not expect it to fix something which is not a complaint.

To Reproduce

Create a solution with a C# code DLL project and an NUnit test project. Add the NUnit.Analyzers package to the test project, and add a project reference from the Test project to the code project.

I have a global.json file alongside the solution to pin to SDK 8.0

{
  "sdk": {
    "version": "8.0.0",
    "rollForward": "minor"
  }
}

In the code project add this class:

internal sealed class NameCleaner
{
    private NameCleaner _decorated;

    public void Example()
    {
        _decorated = new NameCleaner();
    }
}

in the test project add this class

using NUnit.Framework;

[TestFixture]
public class NameCleanerTests
{
    private NameCleaner _sut;

    [SetUp]
    public void SetUp()
    {
        _sut = new NameCleaner();
    }

    [Test]
    public void Placeholder()
    {
        Assert.Pass();
    }
}

Notice how these are both classes, each with a non-nullable field which is not initialised by the constructor, but by a method. The code class correctly highlights the CS8618 in the Visual Studio IDE with a squiggle, and when compiling, and would need fixing by (for example) making the field nullable.

By comparison, the field in the TestFixture does not receive CS8618, because it is suppressed by NUnit3002. this can be proven by temporarily commenting out the [SetUp] attribute line - ensure you leave it uncommented.

Now run dotnet format on the solution. It "fixes" both the code and the test (on my machine, it adds a ? to the field's type; on a GitHub build server, it's changing the field to be required - I haven't pinned down exactly why there is a difference, I'm assuming it's using a different version of the SDK or something).

This definitely relates to the CS8618 complaint because if you create a .editorconfig file alongside the solution and add these lines to it:

[*.cs]
dotnet_diagnostic.CS8618.severity = none

Then this prevents the files being fixed. And my work-around for now is to change the section to be [*Tests.cs] so that it only suppresses CS8618 in test fixtures, which will work for me, but maybe not everyone names their test fixtures that way.

Exceptions (if any)

n/a

Further technical details

details of dotnet --info