Note: I expected to see the warning IDE0370 in the build CI legs (since the removal of the unnecessary suppressions is not merged yet) but it's missing. I can repro that with a simple app locally, but replacing the CodeStyle DLLs with ones from roslyn's main fixes that, so I'm assuming that's some already-fixed bug and these warnings will light up in Roslyn CI as well once the fixed CodeStyle assemblies flow back here through SDK.

but replacing the CodeStyle DLLs with ones from roslyn's main fixes

Terrifying/fascinating. I hate that this is so complicated. :)

Actually, i'm fairly certain we can't enable this.

THe core problem is this:

1. Analyzers run per project/compilation, and have no information about other projects (including the different TFMs they are compiled into).
2. This is a problem because the same project in two separate TFMs may report an unnecessary suppression that can't actually be removed. (it's unnecessary in one tfm, but necessary in the other).

This is not a problem in the IDE/fixer because the fixer has knowledge of the entire solution, and only remove suppressions that are reported in all the TFMs for a project. So it only removes the suppressions that are completely safe to remove.

Could we enable the analyzer and replace the few problematic suppressions (those in shared files) with assertions?

Could we enable the analyzer and replace the few problematic suppressions (those in shared files) with assertions?

Yes. Or change the apis that are called to annotated apis we control. IIRC it's a bunch of annoying apis (likek those in Path and string). But we have things like RoslynPath and RoslynString as alternates for these projects.

Note: my general point is that if we do enable, we should likely attempt to see what will fail up front and fix in the same PR. i'm worried about enabling this, then having someone down the line attempt to update the SDK and then end up with dozens or hundreds of issues to fix. that's going to eb painful.