Unexpected ruleConfiguationOverrides entries in SARIF

[MattKotsenas]

Version Used: .NET SDK 9.0.100

Steps to Reproduce:

I don't yet have a minimal repro, but this appears to be 100% reproducible.

1. git clone https://github.com/MattKotsenas/moq.analyzers.git
2. git checkout repro/sarif-duplicate-entry
3. dotnet clean && dotnet build
4. notepad .\artifacts\obj\Moq.Analyzers\debug\Moq.Analyzers.sarif (this is a SARIF v2 file)
5. if you look in the section runs > invocations > ruleConfigurationOverrides you'll see two descriptors for S3267:

{
  "descriptor": {
    "id": "S3267",
    "index": 1122
  },
  "configuration": {
    "level": "warning"
  }
},
{
  "descriptor": {
    "id": "S3267",
    "index": 1122
  },
  "configuration": {
    "level": "note"
  }
},

Diagnostic Id:

This bug report uses S3267, which is from Sonar, but I don't believe this is related to the Sonar analyzer and instead is a bug somehow related to #67365.

Expected Behavior:

Because this .editorconfig rule override applies to the whole repo (set in commit 0c74755), I would expect only a single entry with the level of note.

Actual Behavior:

Two ruleConfigurationOverride entries, 1 with warning and 1 with note. That suggests that the compiler believes that somewhere in the compilation this rule is set to warning, which I don't think should be the case.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[carstencodes]

Hi,

I currently stumble across the same issue.

External tools have issues importing the sarif files. Any news on that?

[carstencodes]

/cc @jjonescz

[MattKotsenas]

Also /cc @jaredpar who I know started to look into this, but I'm not sure how far you got

[jjonescz]

I took a brief look and the behavior seems expected to me. See the docs for ruleConfigurationOverrides:

Note that we can have multiple ruleConfigurationOverride entries for the same descriptor if the rule is configured to fire at different severities across different parts of the compilation.

You suppress the diagnostic in an .editorconfig under [*.cs] so in all other files the diagnostic would still be a warning. I tried moving the diagnostic to a .globalconfig file and there is just one SARIF entry for it then.

[carstencodes]

Hi @jjonescz

Then I may have a different issue.

I have added a rule to my globalconfig, packed it to a NuGet package and run the configuration.

Ever since I get one entry per finding, not one entry at all with multiple locations.

All with same severity.

The priority should be the same through out all the analysis.

Or is there I way I can analyze the priorities taken?

Regards

Carsten

[jjonescz]

@carstencodes consider providing a minimal reproducible example, ideally in a new issue.

[MattKotsenas]

Thanks for taking a look @jjonescz! I agree with your explanation

For posterity's sake, I wasn't expecting there to be two ruleConfigurationOverrides because in the example [*.cs] does match all the files in the project. However, it also makes sense that the compiler's emitting all the overrides, not just the "effective" or "applied" ones. So that framing along with this doc https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/configuration-files makes it clear that to get the behavior I want for this scenario I should be using .globalconfig.

Thanks for your help!