Add a parser for Roslyn Analyzers SARIF reports

[akash-manna-sky]

Add a parser for Roslyn Analyzers SARIF reports

See : https://github.com/dotnet/roslyn-analyzers
See : https://github.com/dotnet/roslyn

Testing done

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed

[KalleOlaviNiemitalo]

Why is it useful to have a dedicated parser class for these, rather than just use the SARIF parser?

If the same analyser diagnostics are also in the MSBuild logs, then does something deduplicate them? IIRC, the diagnostics in the MSBuild logs do not include all the same properties that are available via SARIF logs, so they might not match in straightforward equality comparisons.

[uhafner]

Why is it useful to have a dedicated parser class for these, rather than just use the SARIF parser?

If the same analyser diagnostics are also in the MSBuild logs, then does something deduplicate them? IIRC, the diagnostics in the MSBuild logs do not include all the same properties that are available via SARIF logs, so they might not match in straightforward equality comparisons.

I also think that such a parser alias does not help a lot. However, the parser descriptor at least provides a simple way to inform users on how to create the reports. So I don't think that adding this parser harms, it is just a simplification.

Or do you have any objections on integrating it, @KalleOlaviNiemitalo?

[KalleOlaviNiemitalo]

I'm concerned that having two equivalent parsers available will confuse users. This could be addressed with documentation.

I'm not sure dotnet build supports /errorlog:roslyn-analyzers-report.sarif. To me that looks more like an option for csc.exe. For dotnet build, I expect -p:ErrorLog=roslyn-analyzers-report.sarif would be needed instead, or perhaps something more complex in a multitargeted project to direct the logs of different compilations to separate files. But I'll check.

[KalleOlaviNiemitalo]

Checked; dotnet build in .NET SDK 10.0.108 does not support /errorlog:roslyn-analyzers-report.sarif. It reports "MSBUILD : error MSB1001: Unknown switch." So the parser's documentation in this PR is actively misleading.

[github-actions]

☀️   Quality Monitor

Tests

     Unit Tests: ✅ successful — 1872 passed $\color{green}{\textsf{(+6)}}$, 2 skipped $\textsf{(±0)}$
   ⛔   Architecture Tests: ✅ successful — 12 passed $\textsf{(±0)}$

Coverage for New Code

   〰️   Line Coverage: 100.00% $\textsf{(±0)}$ — perfect 🎉
   ➰   Branch Coverage: 100.00% $\textsf{(±0)}$ — perfect 🎉

Coverage for Whole Project

   〰️   Line Coverage: 94.49% $\textsf{(±0)}$ — 513 missed lines
   ➰   Branch Coverage: 88.42% $\textsf{(±0)}$ — 390 missed branches

Style

     CheckStyle: No warnings $\textsf{(±0)}$
     PMD: No warnings $\textsf{(±0)}$
   ☕   Java Compiler: No warnings $\textsf{(±0)}$

Bugs

     SpotBugs: No bugs $\textsf{(±0)}$
   🐛   Error Prone: No bugs $\textsf{(±0)}$

API Problems

   🚫   Revapi: 1 warning $\color{green}{\textsf{(+1)}}$ — low: 1

Vulnerabilities

   🛡️   OWASP Dependency Check: No vulnerabilities $\textsf{(±0)}$

Software Metrics

   🌀   Cyclomatic Complexity: 3482 (total)
   💭   Cognitive Complexity: 1963 (total)
   ➿   N-Path Complexity: 4711 (total)
   📏   Lines of Code: 33197 (total)
   📝   Non Commenting Source Statements: 12663 (total)
   🔗   Class Cohesion: 100.00% (maximum)
   ⚖️   Weight of Class: 100.00% (maximum)

📌 Reference Results

Delta reports computed against the reference results of d52c06e in workflow run 26770031087.

🚦 Quality Gates

Overall Status: ✅ SUCCESS

✅ Passed Gates

• ✅ Overall Tests Success Rate: 100.00 >= 100.00
• ✅ Line Coverage in New Code: 100.00 >= 90.00
• ✅ Branch Coverage in New Code: 100.00 >= 90.00
• ✅ Potential Bugs in Whole Project: 0.00 <= 0.00
• ✅ Style Violation in Whole Project: 0.00 <= 0.00

---

Created by Quality Monitor v4.14.3 (#a8d815d). More details are shown in the GitHub Checks Result.

[KalleOlaviNiemitalo]

Tried dotnet build -p:ErrorLog=roslyn-analyzers-report.sarif on a solution with several multitargeted C# projects. That did make a SARIF 1.0.0 file roslyn-analyzers-report.sarif in each project directory but:

• In a multitargeted project, the compiler is run separately for each target framework. The warnings may differ between those compilations (due to #if directives or different reference assemblies) so there should be a separate log for each. Now the log from the later compilation overwrites the earlier one. I suspect that fixing this requires setting the ErrorLog property in a Directory.Build.props file or similar, rather than on the command line.
• Perhaps SARIF 2.1 should be used instead (-p:ErrorLog="roslyn-analyzers-report.sarif%2CVersion=2.1").
• The SARIF logs include diagnostics from analyzers (like NUnit2045 and CA1512), but also from the compiler itself (like CS8981). For that reason, I think the log files should not be named roslyn-analyzers-report.sarif.

[uhafner]

I'm not sure what is better. But since the "new" parser does not do anything different from the Sarif parser it makes sense to drop it. Users will pick up the correct options anyway can use the Sarif format as default. Is it ok for you @akash-manna-sky ?

[akash-manna-sky]

I'm not sure what is better. But since the "new" parser does not do anything different from the Sarif parser it makes sense to drop it. Users will pick up the correct options anyway can use the Sarif format as default. Is it ok for you @akash-manna-sky ?

Let keep it, I will investigate and inform you later.