provide fix all ability to CodeRefactoringProvider

[heejaechang]

fix all is just a concept of scope. not something tightly coupled with the concept of diagnostics or code fixer or code refactoring.

we should provide a way to let users select a scope for CodeRefactoringProvider (http://source.roslyn.io/#Microsoft.CodeAnalysis.Workspaces/CodeRefactorings/CodeRefactoringProvider.cs,11)

...

proposal will be

1. add RefactoringFixAllProvider as in CodeFixProvider.GetFixAllProvider
   http://source.roslyn.io/#Microsoft.CodeAnalysis.Workspaces/CodeFixes/CodeFixProvider.cs,33 to CodeRefactoringProvider

which is the same as FixAllProvider but without GetSupportedFixAllDiagnosticIds.

it would be awesome if we can merge those 2, but if we can't, having new type seems fine.

2. FixAllContext for GetFixAsync gets new one RefactoringFixAllContext. again, it would be nice if we can merge those 2 but, if that's a problem (due to it being public API and etc), having new type seems fine to me

and like RefactoringFixAllprovider, RefactoringFixAllContext should not have any API related to DiagnosticIDs but all other ones like Scope, CancellationToken and etc should be provided same.

in this proposal, implementer of RefactoringFixAllProvider will implement the fix all provider almost same way as existing FixAllProvider, only difference will be rather than get code location to apply fix by diagnostics, it will run its own discovery code based on given scope and return fix all code action as existing CodeFix FixAllProvider.

like existing FixAllProvider, we can provide general RefactoringFixAllProvider such as BatchFixAllProvider (http://source.roslyn.io/#Microsoft.CodeAnalysis.Workspaces/CodeFixes/FixAllOccurrences/BatchFixAllProvider.cs,23) by let it accept discoverer that will run on the given scope to find places to call existing CodeRefactoringProvider almost same way as we do for CodeFixProvider.

...

it doesn't need to be the way I proposed above, but the point is us providing a way for user to invoke code refactoring fix all so that it doesn't become a reason to make people to convert refactoring to analyzers.

people should convert one to analyzer if they believe it is something worth to break build in CI. LB or Fix all shouldn't be the reason. in that sense, once we have this, we should consider some of analyzer with hidden diagnostics, whether we should move those to refactoring rather than analyzers.

[heejaechang]

tagging @mavasani @sharwell @jinujoseph for more idea.

[heejaechang]

an alternative approach will be just adding these API to existing CodeRefactoringContext

1. scope (document/project/solution)
2. solution/project/document (one that scope is associated with)

and.. that will be it.

it has its own disavantage like using 1 thing for multiple purpose, how to offer general fix all provider and etc.

[sharwell]

an alternative approach will be just adding these API to existing CodeRefactoringContext

We would need a way to determine whether a refactoring supports Fix All operations. With the dedicated RefactoringFixAllProvider type, this would work the same way it works for code fixes (return null to indicate not supported), which is a good thing IMO.

[mavasani]

@heejaechang I like your first proposal, and I completely agree that we should try as much as possible to retain the API shape that we have for code fix provider API (GetFixAllProvider, GetFixAsync, FixAllContext, etc.). Given that existing types FixAllProvider, FixAllContext and CodeFixProvider are all in namespace Microsoft.CodeAnalysis.CodeFixes, while CodeRefactoringProvider is in namespace Microsoft.CodeAnalysis.CodeRefactorings, we should probably introduce new types Microsoft.CodeAnalysis.CodeRefactorings.FixAllProvider and Microsoft.CodeAnalysis.CodeRefactorings.FixAllContext, which are pretty much identical to the existing code fix specific fix all types, except for diagnostic and code fix specific APIs.

[CyrusNajmabadi]

@jnm2 i think you were interested in this as well :)

[CyrusNajmabadi]

I have an alternate proposal here. Allow a CodeAction to be queryable for 'Fix Scopes' that it would support. These would basically be set of strings, like "current method" "current type" "entire project" that would then be used to populate the UI in hte preview window so it could offer:

Fix all in 'current method' | Fix all in 'current type' etc. etc.

There would then be a new entrypoint on the CodeAction called Task<Solution> GetChangedSolutionForScope(Solution, string scope, CancellationToken).

The action could then perform whatever logic it wanted there to support this.

thoughts @mavasani

[CyrusNajmabadi]

Note: i prefer the above because i've always struggeld with FixAll with analyzers in how they're disconnected from teh particular Diagnostic+Fix that i reported from my analyzer. I need to do all this work with properties/ids/descriptors/equivalence-keys to associate the right fix-all behavior with the right actions.

Having these be tied together at the action level cleans that all up and allows each fix to have entirely custom fix-all behavior that doesn't need to be reinferred through other means.