Sonar-dotnet: False positive on S3453 when using target typed new for static readonly variables within the same type.

[AraHaan]

Description

When using the new new() syntax for target type newing things in C# 9, the analyzer throws S1172 thinking the ctor of that type is unused when it is (it's just called using target typed new)

Repro steps

namespace UnluacNET
{
    using System;

    public class LBoolean
    {
        public static readonly LBoolean LTRUE = new(true);
        public static readonly LBoolean LFALSE = new(false);

        private LBoolean(bool value)
        {
            this.Value = value;
        }

        private bool Value { get; set; }

        public override bool Equals(object obj)
            => this == obj;

        public override int GetHashCode()
            => throw new NotImplementedException();

        public override string ToString()
            => this.Value.ToString();
    }
}

Expected behavior

I expect the analyzer to properly pick up that target typed new is used and that the specific ctor is actually called and not offer to remove it. Removing it would result in a compile error due to that fact. True I could replace the ctor with an initializer on the static readonly variables to initialize the property, but it's shorter to just use the ctor.

Actual behavior

The analyzer flags the ctor as unused and offers to delete it.

Known workarounds

1. disable the diagnostics from this rule using .editorconfig.
2. initialize the property within the static readonly variable and invoke the compiler generated ctor using target typed new.

Related information

• C#/VB.NET Plugins version: not used.
• Visual Studio version: latest preview version
• MSBuild / dotnet version: latest from the .NET 6 Preview 3 SDK.
• SonarScanner for .NET version (if used): not used.
• Operating System
  Windows 10 latest dev insider preview && MacOS 11.3 Big Sur (2 different pc's)

[costin-zaharia-sonarsource]

@AraHaan, as far as I can tell the issue raised is S3453 not S1172. Do you confirm?

Our support for C# 9 is quite limited at this point. Improving it is a priority for us and it will be tackled in the next few months.

I will close this issue as it is a known limitation which we already plan to fix.

[costin-zaharia-sonarsource]

A test case for this problem can be found here: https://github.com/SonarSource/sonar-dotnet/blob/0dfe4f9bd5a457684f97c6ae97cfdb360c533b70/analyzers/tests/SonarAnalyzer.UnitTest/TestCases/ClassNotInstantiatable.CSharp9.cs#L78-L87

[AraHaan]

Ah sorry I might have identified the number on it wrong.

[costin-zaharia-sonarsource]

Ah sorry I might have identified the number on it wrong.

No worries, thanks a lot four your feedback!

[dougwaldron]

I came here to report this. Is there a place to track progress on the planned fix? Also, can you change the title of this issue to show the correct rule so it's easier to find?

[costin-zaharia-sonarsource]

Is there a place to track progress on the planned fix?

Not yet.

[pavel-mikula-sonarsource]

You can track MMF-2225. This issue should get fixed as part of it.

To be clear, there's no ETA for the MMF, but C# 9 support is already in progress as many things needs to be done on the topic.