Rule S3887: Mutable, non-private fields should not be "readonly" (Bug warning) is not caught by sonar scanner and it is not displayed in the report on SonarQube 8.2 version community edition

I’m using SonarQube sonarqube-8.2.0.32929 community edition, sonar scanner sonar-scanner-msbuild-4.7.1.2311-net46

The warning for the rule S3887: Mutable, non-private fields should not be “readonly” (Category: Bug) is not caught by sonar scanner and it is not displayed in the report.

E.g. Analyzing :

using System.Collections.Generic;
/// <title>Mutable, non-private fields should not be "readonly"</title>
/// <summary>
/// Using the readonly keyword on a field means that it can't be changed after initialization. However, when applied to collections or arrays, 
/// that's only partly true. readonly enforces that another instance can't be assigned to the field, but it cannot keep the contents from being updated. 
/// That means that in practice, the field value really can be changed, and the use of readonly on such a field is misleading, and you're likely to not be getting the behavior you expect.
/// This rule raises an issue when a non-private, readonly field is an array or collection.
/// </summary>
namespace SonarQubeToolVerification.Bug.Warnings
{
    public class S3887Warning
    {
        public readonly int[] intArr;  // Noncompliant
        public readonly LinkedList<int> intList;  // Noncompliant
    }
}

Waiting for Bug warning:

S3887: Mutable, non-private fields should not be “readonly”
but nothing displayed in the report.

Any suggestions?

hi @mike1970fl03

This is by design - check this explanation from our test cases:

When the types are uninitialized, this is equivalent to being initialized to null so we don’t report

This behavior was added in #1695

When a mutable readonly field is not initialized, this is equivalent to being initialized with null . As the rule doesn’t report on the latter it should not report on uninitialized fields.

We don’t raise when a read-only collection field is initialized with null because we consider it an immutable value.