Reimplement codeformatter "rules" as Roslyn analyzers/fixers

[ghost]

Codeformatter's command line interface will remain the same. The user of codeformatter won't notice that the rules are now implemented as analyzers/fixers; that’s an implementation detail. Codeformatter will simply calls the Roslyn APIs to run the analyzers/fixers.

The advantage is that VS users will be able to use the analyzers/fixers as well. In other words, the effort here is to make the rules/fixes use the Roslyn extensibility model and make codeformatter a simple command line driver for it.

Sri prototyped the technique in his version of FormattingEngineImplementation.cs in his fork of codeformatter. The important part is his reimplementation of the method FormatProjectAsync. It runs the analyzers by creating a CompilationWithAnalyzers and calling GetDiagnostics on it. Then it runs the fixers, and applies the fixes to the workspace.

In the prototype, Sri completely removed the existing “rule-based” implementation ("driver") in FormatProjectAsync. But in the actual implementation, the two drivers will exist side by side. FormatProjectAsync will continue to call the rule-based driver unless the command line option /UseAnalyzers is present, in which case it will call the new analyzer-based implementation. This will allow us to do perf comparisons as we reimplement each rule, for example:

codeformatter MyProject.csproj /Rule:ThisRule,ThatRule
codeformatter MyProject.csproj /UseAnalyzers /Rule:ThisRule,ThatRule

When all the rules have been reimplemented as analyzers, we will remove the rules, and remove the rule-based driver from the engine.

The analyzer-based implementation will have to take care to run the analyzers in such a way that fixes from different analyzers don’t overlap and interfere with one another. We will add an Attribute to the analyzers that can all run together in a single compilation; the others will each run in a separate compilation.

We will place the analyzers/fixers in their own project, separate from the engine, so we can ship them in a NuGet package without having to ship the engine.

[Priya91]

Sounds good.

[twsouthwick]

@Igolding Are you still working on this?

[ghost]

Yes, kind of a long term effort :) + @michaelcfanning.

[michaelcfanning]

Yes, in flight. :) We need to reauthor the range of existing checks as analyzers. We should enable codeformatter to drive arbitrary analyzers. We need to good configuration story for the analyzers (as these checks are mostly highly configurable).

[stebet]

I'm very much looking forward to this. Is there a repo we can contribute into to help with this task?

[jaredpar]

@stebet this work is going on in the anfix branch

https://github.com/dotnet/codeformatter/tree/anfix

[dnperfors]

I didn't know there was already work like this done, so I started my own project for analyzers: https://github.com/dnperfors/CodeStyleAnalyzer There is already a version available on NuGet