[release/10.0.3xx] Use suppressors when applying code fixes

[github-actions]

Backport of #53268 to release/10.0.3xx

#48512 fixed suppressors during analysis, but they aren't run when applying code fixes, which can cause fixes to be applied for diagnostics that should have been suppressed.

This only happens when there's a mix of suppressed and unsuppressed diagnostics, because if all diagnostics of a certain type are suppressed, it will bail out earlier.

Tactics

Summary

dotnet format incorrectly applied code fixes to diagnostics that should have been suppressed by DiagnosticSuppressor analyzers. PR #48512 previously added suppressor support to the analysis phase, but the code-fix path in AnalyzerFormatter.FixDiagnosticsAsync selected analyzers solely by matching SupportedDiagnostics against the diagnostic ID — it never included DiagnosticSuppressor instances, which only expose SupportedSuppressions. The fix adds a single OR clause to the LINQ Where predicate to also select any DiagnosticSuppressor that suppresses the target diagnostic ID, ensuring suppressors participate when fixes are applied. The change is surgical and self-contained, making it well-suited for a servicing release.

Customer Impact

Users of dotnet format whose projects include DiagnosticSuppressor-based analyzers experience incorrect file modifications: suppressed diagnostics are "fixed" when they should be left alone. The most common real-world scenario involves Unity projects using Microsoft.Unity.Analyzers, where the suppressor prevents IDE0044 ("Make field readonly") from being applied to [SerializeField]-marked fields — without this fix, dotnet format --fix-style silently corrupts those fields. The issue affects all SDK releases that include PR #48512. The bug only manifests when the same diagnostic ID has a mix of suppressed and unsuppressed instances in the same project; fully-suppressed diagnostics bail out earlier and are unaffected. No simple per-project workaround exists short of disabling the diagnostic entirely in .editorconfig.

Regression?

Not a traditional regression — this is a pre-existing deficiency in the code-fix path that predates PR #48512. When #48512 landed it wired up suppressors for the analysis phase but did not update the fix-application path, leaving a gap. The bug was not easily observable until suppressors were respected during analysis (post-#48512), at which point the mismatch became apparent. No single PR introduced a behavioral change that used to work correctly.

Testing

A new MSBuild-fact unit test SuppressedDiagnosticsAreNotFixed was added to test/dotnet-format.UnitTests/CodeFormatterTests.cs. It runs dotnet format --fix-style against a new test project (suppressor_fix_project) that contains two source files: Program.cs (a Unity MonoBehaviour subclass with a [SerializeField]-marked field, suppressed by Microsoft.Unity.Analyzers) and Program2.cs (a plain class with the same unsuppressed field). The test asserts that only Program2.cs is modified. CI ran on the originating PR (#53268) against main before it was merged and then backported here.

Risk

Low. The production change is a 5-line modification (4 added, 1 deleted) confined entirely to a single LINQ Where predicate in AnalyzerFormatter.FixDiagnosticsAsync. The added condition is gated by a type-check (is DiagnosticSuppressor), so all existing behavior for non-suppressor analyzers is completely unchanged. The fix only expands the set of analyzers passed to RunCodeAnalysisAsync for the fix phase — it does not alter fix selection or application logic. A dedicated regression test covers the exact scenario being fixed.

[JoeRobich]

/tactics