Use BatchFixer to fix all for naming violation

[Cosifne]

Fix issue: #14983

Use BatchFixer to support fix all for IDE1006.

NameStyleFixerProvider is used both in CodeStyle & workspace
If it lives in workspace, it needs to call IRefactorNotify after renaming.
If it lives in CodeStyle, it doesn't need to do that.

This fix is based on this PR #55033, in order to call IRefactorNotify correctly. Otherwise, we need to find another way to reuse BatchFixer

TODO:
Add tests and refactor all the tests using the new Test API.

P.S. Thanks to Jon's help

[Youssef1313]

If the resource is being changed anyway, I think the casing should be fixed to be consistent with other codefix titles.

Suggested change

	<data name="Fix_Name_Violation" xml:space="preserve">
	<value>Fix Name Violation</value>
	<data name="Fix_name_violation" xml:space="preserve">
	<value>Fix name violation</value>

[sharwell]

❗ The batch fixer won't correctly handle naming conflicts created by parallel fixes. This is a blocking issue.

[Cosifne]

As we sync offline, the possible case is
Task 1: symbol-A renamed to 'B'
Task 2: symbol-B renamed to 'A'
and it will change the semantics of the program.

Then it means the job can't be done concurrently.
How about renaming the symbol sequentially, and when renaming this symbol cause conflicts, skip it, and do the next one.
This would at least let people can fix all naming problem if their repo doesn't contain conflicts

[jmarolf]

Why is this not a blocking issue on the five other BatchFixers that use the rename API? Isn't this case applicable to all of them?

[CyrusNajmabadi]

Which fixers are those? Thanks!

[Cosifne]

I should post what I discuss with Sam offline here to make it more clearly.
What Sam was worried about is because BatchFixer computes changes in different documents separately,
If there is a document A:

public class iNotifyFile { }

And also there is a document B

public interface NotifyFile { }

Then batchFixer will generate
Document A

public class INotifyFile { }

Document B

public interface INotifyFile { }

which caused a naming collision.
The other AnalzyerFixers using both BatchFixer and Renaming API, (I guess @jmarolf means UseAutoPropertyFixer, MakeMethodAsyncFixer and the MakeMethodSync version are not having such great power in renaming.

[Cosifne]

@jmarolf
Do you feel this would be a current acceptable solution? I also talked to @sharwell about this.
In the fix all fixer, first check the naming swapping (this could be done if create a hashset and put all the before/after naming string in it), filter all of these symbols out.
Then use a similar way like the batch fixer. (Rename symbols, calculate & merge the document text diff)
The downside is this fixer becomes a 'Fix most' solution and this would be slow for large code base. (As @CyrusNajmabadi and Sam mentioned above)

[jmarolf]

I guess we should have a meeting about this :( From my perspective the important bit is that fix all fixes all. It can be slow but if it's not as slow as me individually applying the fix to each diagnostic manually (what we have today) it's a productivity enhancement in my book.

Lets not get too cute here. What is the simplest design that can work? It would also be super helpful if we wrote a test case for the situation @sharwell is concerned with so it's obvious to me what the problem is.

[Cosifne]

Sure, I am going to create a meeting and sync offline

[Cosifne]

The conclusion of the offline discussion:

1. The impl should be based on a new renaming API, which supports renaming a set of symbol based on a single solution snapshot.
2. The fix all should only fix based on a single rule & symbol kind.

[ericsampson]

is this feature work still alive? :)