dotnet
EditorConfig comments cannot follow a property value
Related to editorconfig/specification#23 and editorconfig/specification#31
Fixes #44596
⚠️ This is a breaking change for users who previously wrote comments at the end of lines in .editorconfig. I wasn't able to find a specific example but @Youssef1313 found this one:
https://github.com/dotnet/roslyn/blob/7464573942d364bc8a33c04ec46ac5835e3d90ba/src/Features/Lsif/Generator/.editorconfig#L4-L5
💭 I do notice that all cases we've found that seem to be affected involve a dotnet_diagnostic line. Since this is a compiler-controlled property interpretation, we do have the option of modifying the interpretation of that value to ignore text after a ; or #.
Needs a parallel change in roslyn-analyzers:
roslyn-analyzers already doesn't follow the spec, so I'd rather delete the custom support there than try to maintain it.
Just saw Jon's comment above. I'll mark this PR as draft for now. Did we start a conversation to confirm the desired behavior?
Lets not merge this until we get confirmation that this is actually the correct behavior. There seems to be some belief that this is a spec defect
@jmarolf @jcouv @sharwell The spec is now updated https://github.com/editorconfig/specification/pull/31 and it's clear what the correct behavior is.
Can this get reviewed and merged?
Any progress on this? This issue makes inserting the GPL license text impossible as it gets truncated.
Few popular repositories that are going to be affected:
- https://github.com/xamarin/xamarin-android/blob/aaa37c3df94490ee9befb8381f4dd7aa18226355/.editorconfig#L218
- https://github.com/DotNetAnalyzers/IDisposableAnalyzers/blob/c8e3f323ff7d31d8271c9a013f1932d6f743e2de/.editorconfig#L207
- https://github.com/dotnet/project-system/blob/7ab8083659d0d54722463aab3990efaf37b4d894/.editorconfig#L232
Note that none of these will be affected now that dotnet_diagnostic.*.severity parsing has been updated to ignore text that was previously a comment.
Overall though I love the approach to maintain compat -- simply treating this as a break would have been far too icky for these scenarios.
What's the status of this PR? Since the PR documents the breaking change in .NET 9, is it safe to assume it will be merged for that release?
