Adding files to map compiler diagnostics to built-in code fixes

[Neme12]

Idea from #23326 (comment):

@sharwell That list is very nice, but it's a bit empty. Do you think it would be a good idea to put that somewhere in the Roslyn repo as a markdown file (maybe /docs/ide) so that anyone could contribute to it, either by linking to an issue they created or a code fix?

Perhaps that file could also link to the spreadsheet.

also tagging @jinujoseph

The code fix fields are currently empty, but adding these files to the repo would allow contributors to fill them in if they file an issue, make a new code fix or simply decide to fill out the existing code fixes.

The diagnostics for both languages are updated with current master branch.

[sharwell]

Speaking from experience, this is really hard to maintain by hand, both for auditing the current state and proposing new fixes.

• Many error codes have fixes for certain conditions, but additional fixes may be relevant
• Many fixes apply to multiple error codes

[Neme12]

@sharwell But the issues are created by hand. How would you like to automate linking issues to the diagnostics they're asking a code fix for?

[Neme12]

Many error codes have fixes for certain conditions, but additional fixes may be relevant

You're right. That's why I called the column "Code fixes" as opposed to "Code fix".

Many fixes apply to multiple error codes

Why is that a problem?

[Neme12]

@sharwell We could write a tool that would go through Roslyn, find all the code fixes that fix compiler diagnostics and add them to this document. What do you think about that?

The issue management would still need to be manual though,that's why this would be a hand-editable document that people can contribute to.

[sharwell]

We could write a tool that would go through Roslyn, find all the code fixes that fix compiler diagnostics and add them to this document. What do you think about that?

Overall, I've been very happy with this as a targeted solution. For example, the JSON file backing the StyleCop Analyzers Status page is produced by code analysis that runs in the AppVeyor build. This would certainly be feasible for the "current state" problem, but doesn't address the linked issues. I never found a solution to the whole thing I was super happy with, and didn't want to commit to something I wasn't happy with considering there are over 1,000 codes to keep track of.