Pausing on this to try to figure out a good way to order the review.

@mavasani Is this something we can break into multiple commits?

Is this something we can break into multiple commits?

Let me break this into separate commits and force push...

@jasonmalinowski @CyrusNajmabadi I have updated the PR to be split into multiple commits, hopefully it is easier to review.

1. Commits 1-3: All the analyzer config document plumbing through Workspaces, EditorFeatures and Visual Studio layers
2. Commit 4: Analyzer config and additional document test infrastructure support
3. Rest of the commits - Support for the new code action and unit tests

I will now work on refactoring/sharing more code for analyzer config documents. Note that it is likely going to lead to helper methods with bunch of ugly lambdas, but probably that is better then cloning large pieces of code.

@mavasani Thanks for putting in that effort!

• 4c0459a25a556db891b467ed713e53415374095b. Small nits, some concerns about default switch behavior. Strongly think we should invest in a non-duplicative approach to files. But that's a non-blocking concern.
• d839a0623c8507bb562dd78079bd1dc2133eb530. Looks fine. As per the comments, there's opportunity for sharing. Would like to see that done, but it's non-blocking.
• 061b7108b23e049f9b3eeb9c0ad7c30ba64cd564. Looks fine. Makes me def want a better way to pass around information about a Document. I think we should have the base TextDocument have an enum-kind on it stating what sort of doc it is.

Note: the above commits look like they could be broken out into their own PR without the feature. Up to you if you want to do that.

• 9348874797c8020cfd213f4394cdc04cb78bcc00. LGTM
• 9a0e198a61289262d9d0cbb06263e75bddd20dcf. Strong opposition. I think this is a cutting-corners approach to this problem to avoid a proper design that any analyzer could play in. I've given similar feedback in the past about how our features which should be isolated are now leaking all over the codebase to make other features work. This just continues that and i think it needs to stop.
• 2d76f29044e0fe8dd5c7336f3a7b9cecbb00b69f. Don't hate me, but i think ISuppressionOrConfiguration is really superfluous. I think this could just be IConfiguratoinXXX or ICodeFixConfigurationXXX. Configuration (to me) implies being able to do things like suppress and/or change severity. I don't think all the sub-purposes need ot be elevated into the name of the type.
• 3ac247f435ae0a63aa7e03f1db1f31e22ee4d7f2. Skipped reviewing tests for now.
• 74ae159267b2a15c7a36b7e835d49d09d7527c46. Somewhat skimming at this point.

@CyrusNajmabadi - I have reverted 1fb9371 for tracking mapping of diagnostic IDs to code style options. I have taken an alternate approach in 5b6cee9, which now requires each analyzer to explicitly provide the associated option with each supported descriptor. I will look at your other review comments now.

@mavasani Thanks for the change! I'm much happier with it. It def satisfies at least one of my goals, which is that the beahvior and description of the feature is contained within the feature itself. My other goal (which is absolutely not required and can come later) would be that this be a general part of the code-fixer infrastructure, and not limited to just our internal features.

My objection is withdrawn on that commit now. Thanks!

@CyrusNajmabadi I have addressed most of your review feedback with the latest commit.

@dotnet/roslyn-ide @heejaechang - would you be able to review this PR?

@CyrusNajmabadi I have addressed most of your review feedback with the latest commit.

@mavasani Thanks! Will try to review this this weekend. I don't expect any issues, your responses all seemed sensible to me :)

FYI: I have pushed a new commit f1511b8, which adds a configuration fixer to enable configuring IDE code style option values from the lightbulb. I have updated the PR description and screenshots.

Tagging @jinujoseph @kendrahavens @mikadumont

the pictures are awesome. Can you show what it looks like to change the severity in this case:

I currently chose the implementation to add/update all code style option based entries instead of using dotnet_diagnostic.IDE0008.severity = error, which might add confusion as a subsequent entry for code style option will conflict with this entry. I felt it would be good to stick to following principle:

1. Always use code style option based syntax (i.e. optionName = optionValue:severity) for IDE code style diagnostics.
2. Always use compiler based syntax (i.e. dotnet_diagnostic.ID.severity = severity) for 3rd party diagnostics and non-code style IDE diagnostics.