Analyzers prototyping - Configuration module

[JanKrivanek]

Context

#9627

Configuration module will be responsible for loading user settings from .editorconfigs in a structured form. The OM for configuration will yet be determined - we should be able to support strongly typed configuration, but it will be known at compile time and can be assumed 'hardcoded'. It should as well be possible to pass-through a custome key-value pairs as configuration - basically anything that is not recognized by existing OM will be stuffed to a lookup and provided to the analyzer.
Note .editorconfig files are hierarchical - more details https://editorconfig.org/#file-location
Plus .editorconfig might be included in nuget packages and written to source location during restore phase. Thiough for a V1 we might just decide to ignore configuration changes upon build start.

Things to be investigated and decided

• Rules group, naming (e.g. dotnet_diagnostic.MSB00123.severity = warning)
• Any additional support for grouping? (e.g. how to effectively distinguish all rules imported from specific package)
• Where/How to discover .editorconfig files (e.g. Roslyn consider hieratchical editorconfig files in included sources locations plus packed in regular nugets or analyzer nugets)

References

• https://editorconfig.org/
• https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/configuration-files
• Roslyn imlementation:
  • https://github.com/dotnet/roslyn/blob/8a7ca9af3360ef388b6dad61c95e2d0629d7a032/src/Compilers/Core/Portable/CommandLine/AnalyzerConfig.cs
  • https://github.com/dotnet/roslyn/tree/8a7ca9af3360ef388b6dad61c95e2d0629d7a032/src/Workspaces/SharedUtilitiesAndExtensions/Compiler/Core/EditorConfig
• https://www.mytechramblings.com/posts/configure-roslyn-analyzers-using-editorconfig

Followup work in scope of this epic:

• Configuration - ConfigurationContext should contain infra config as well #10123
• [Feature Request]: Expand BuildCheck editorconfig allowable syntax #10232
• Multiword configuration options renaming #10315

Moved to post-net9.0:

• Research and implement rules/analyzers identification and filtering strategy #9823
• Configuration - decide fate and form of 'Category' #10314

[f-alizada]

@JanKrivanek thanks for the detailed description!
I have few clarification questions:

• (The OM for configuration will yet be determined - we should be able to support strongly typed configuration) Do I understand correctly that we are referring here to the known properties for example: IsEnabled, Severity or any other predefined analyzer or we are aiming to support all properties as strongly typed?
• Where/How to discover .editorconfig files (e.g. Roslyn consider hieratchical editorconfig files in included sources locations plus packed in regular nugets or analyzer nugets) Could you please clarify the concerns with following the specification of editorconfig, not to introduce different implementation with different behaviour.

[JanKrivanek]

• Strong typing - the infra requird configuration will be known at compile time (and changing rarely if ever) - so that can be hardcoded. Everything else discovered in editorconfig will be passed just as strings key-value pairs (and this is not even strong requirement for v1)
• discovery - any location being discovered will follow the standard of going up the folder structure, untill root=true is hit in editorconfig or untill root of the driv is hit. That means that the configuration will need to be given for specific locations (the caller of the Configuration module will need to specify location). The .editorconfig files can as well be placed as resources in the nuget file and appear in the sources tree during the restore/evaluation time - this probably won't change implementation, as analyzers will run after the restore phase and hence all .editorconfig files will be already in place. But it might be good idea to check with Roslyn team whether they chosen to somehow special-case handle such .editorconfig files packed within nugets.