EditorConfig comments cannot follow a property value#51625
EditorConfig comments cannot follow a property value#51625sharwell wants to merge 6 commits intodotnet:mainfrom
Conversation
Youssef1313
left a comment
There was a problem hiding this comment.
Would you update this as well?
Youssef1313
left a comment
There was a problem hiding this comment.
Needs a parallel change in roslyn-analyzers:
Youssef1313
left a comment
There was a problem hiding this comment.
Few popular repositories that are going to be affected:
roslyn-analyzers already doesn't follow the spec, so I'd rather delete the custom support there than try to maintain it. |
jmarolf
left a comment
There was a problem hiding this comment.
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
|
|
||
| [Fact] | ||
| public void EndOfLineComments() | ||
| [Theory] |
There was a problem hiding this comment.
Please document the breaking change in https://github.com/dotnet/roslyn/blob/main/docs/compilers/CSharp/Compiler%20Breaking%20Changes%20-%20post%20DotNet%205.md #Closed
There was a problem hiding this comment.
➡️ Documented for .NET 9
| var trimmed = value.AsSpan(); | ||
| var commentStartIndex = trimmed.IndexOfAny(commentStartCharacters); | ||
| if (commentStartIndex >= 0) | ||
| trimmed = trimmed[0..commentStartIndex].TrimEnd(); |
There was a problem hiding this comment.
As far as I understand, this change is to maintain the existing behavior and I assume we already have tests covering this. Is that right? #Closed
There was a problem hiding this comment.
➡️ Yes, and tests have now been added.
|
Just saw Jon's comment above. I'll mark this PR as draft for now. |
@jmarolf @jcouv @sharwell The spec is now updated editorconfig/specification#31 and it's clear what the correct behavior is. Can this get reviewed and merged? |
| private static readonly Regex s_sectionMatcher = new Regex(@"^\s*\[(([^#;]|\\#|\\;)+)\]\s*([#;].*)?$", RegexOptions.Compiled); | ||
| // Matches EditorConfig property such as "indent_style = space", see https://editorconfig.org for details | ||
| private static readonly Regex s_propertyMatcher = new Regex(@"^\s*([\w\.\-_]+)\s*[=:]\s*(.*?)\s*([#;].*)?$", RegexOptions.Compiled); | ||
| private static readonly Regex s_propertyMatcher = new Regex(@"^\s*([\w\.\-_]+)\s*[=:]\s*(.*?)\s*$", RegexOptions.Compiled); |
There was a problem hiding this comment.
[=:]
Why are we considering both = and : to separate the key and the value? I don't think key : value should be allowed.
There was a problem hiding this comment.
➡️ I have no idea, but that seems beyond the scope of this change.
|
Any progress on this? This issue makes inserting the GPL license text impossible as it gets truncated. |
| "refactoring" => ReportDiagnostic.Hidden, | ||
| "suggestion" => ReportDiagnostic.Info, | ||
| "warning" => ReportDiagnostic.Warn, | ||
| "error" => ReportDiagnostic.Error, |
There was a problem hiding this comment.
would prefer these just be arguments to this test method, so the switch isn't needed.
There was a problem hiding this comment.
would prefer these just be arguments to this test method, so the switch isn't needed.
➡️ The current form is intentional. Arguments to the test method are input state and are used to define the unique ID of the test itself. Expected results should not be inputs, and changing an expected outcome should not be part of the test identity.
There was a problem hiding this comment.
I'd agree with Cyrus here -- we normally put the expected as an input too...
There was a problem hiding this comment.
we normally put the expected as an input too
➡️ I try to fix these when they occur in a method I'm working on. Test parameterization should only ever exist on the inputs, not the outputs. The entire test identity and reporting strategy (e.g. test historical pass rates, red/green developer iterations in TDD) is built around this premise.
Note that none of these will be affected now that |
| The compiler is updated based on the EditorConfig specification clarification in | ||
| [editorconfig/specification#31](https://github.com/editorconfig/specification/pull/31). This changes the way values are | ||
| passed to analyzers for lines with the following form: |
There was a problem hiding this comment.
The examples are great, but this might be clear too if we just say "comments now must be on their own line; comments after a value are treated as a part of the value."
There was a problem hiding this comment.
➡️ Updated the text
|
|
||
| ## .editorconfig values no longer support trailing comments | ||
|
|
||
| ***Introduced in Visual Studio 2022 version [TBD]*** |
There was a problem hiding this comment.
This is just a reminder to fix this prior to merge.
There was a problem hiding this comment.
❓ Do we know what the value here is going to be?
| "refactoring" => ReportDiagnostic.Hidden, | ||
| "suggestion" => ReportDiagnostic.Info, | ||
| "warning" => ReportDiagnostic.Warn, | ||
| "error" => ReportDiagnostic.Error, |
There was a problem hiding this comment.
I'd agree with Cyrus here -- we normally put the expected as an input too...
| [InlineData("#")] | ||
| [InlineData(";")] |
There was a problem hiding this comment.
I'd consider tweaking the inline data to add another case like:
| [InlineData("#")] | |
| [InlineData(";")] | |
| [InlineData("error # ignored text")] | |
| [InlineData("error ; ignored text")] | |
| [InlineData("warning ; ignored text")] |
As otherwise this test could incorrectly pass if all parse errors were simply converted to ReportDiagnostic.Error.
There was a problem hiding this comment.
➡️ Added a second line inside the test itself.
| /// files. For code style options maintained by Roslyn, we continue to detect and remove these "comments" for | ||
| /// backwards compatibility. | ||
| /// </summary> | ||
| private static readonly char[] s_commentDelimiters = ['#', ';']; |
There was a problem hiding this comment.
Did we want to share this code/list with the compiler code doing the same thing? The file path here makes me think we've already got shared files between both layers to use here.
There was a problem hiding this comment.
➡️ The sharing here is between the workspaces and code style layers. The compiler maintains its own back-compat separately.
|
Overall though I love the approach to maintain compat -- simply treating this as a break would have been far too icky for these scenarios. |
| private static readonly Regex s_sectionMatcher = new Regex(@"^\s*\[(([^#;]|\\#|\\;)+)\]\s*([#;].*)?$", RegexOptions.Compiled); | ||
| // Matches EditorConfig property such as "indent_style = space", see https://editorconfig.org for details | ||
| private static readonly Regex s_propertyMatcher = new Regex(@"^\s*([\w\.\-_]+)\s*[=:]\s*(.*?)\s*([#;].*)?$", RegexOptions.Compiled); | ||
| private static readonly Regex s_propertyMatcher = new Regex(@"^\s*([\w\.\-_]+)\s*[=:]\s*(.*?)\s*$", RegexOptions.Compiled); |
There was a problem hiding this comment.
Probably outside the scope of this PR, but should we be allowing whitespace within the key?
eg:
test value = allowed
There was a problem hiding this comment.
It appears that we do not currently support whitespace inside the key, but according to the specification it should be allowed:
Key: The part before the first = (trimmed of whitespace, but including any whitespace in the middle).
Can you file a new issue for this?
|
Any movement on this? |
|
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? |
|
|
||
| internal static bool TryParseSeverity(string value, out ReportDiagnostic severity) | ||
| { | ||
| ReadOnlySpan<char> commentStartCharacters = stackalloc char[] { ';', '#' }; |
There was a problem hiding this comment.
nit: consider leaving a comment ("for backcompat, ...")
|
|
||
| var comparer = StringComparer.OrdinalIgnoreCase; | ||
| if (comparer.Equals(value, "default")) | ||
| if (trimmed.Equals("default".AsSpan(), StringComparison.OrdinalIgnoreCase)) |
There was a problem hiding this comment.
The comparer local on line above (339) no longer seems to be used
|
|
||
| ## .editorconfig values no longer support trailing comments | ||
|
|
||
| ***Introduced in Visual Studio 2022 version 17.[TBD]*** |
There was a problem hiding this comment.
Tagging @jaredpar to advise on which release to pull this change into, since it involves a compat break. Feels like we should hold this off rather than squeeze it late in the release cycle.
There was a problem hiding this comment.
We should either update this before merging, or open an issue to track updating it once we know which release it landed in.
jcouv
left a comment
There was a problem hiding this comment.
Compiler changes LGTM Thanks (iteration 6)
|
@dotnet/roslyn-compiler for a second review. Thanks |
1 similar comment
|
@dotnet/roslyn-compiler for a second review. Thanks |
|
|
||
| ## .editorconfig values no longer support trailing comments | ||
|
|
||
| ***Introduced in Visual Studio 2022 version 17.[TBD]*** |
There was a problem hiding this comment.
We should either update this before merging, or open an issue to track updating it once we know which release it landed in.
jaredpar
left a comment
There was a problem hiding this comment.
Putting a hold on this given it's a breaking change in editorconfig and we're trying ot discuss what paths for that look like.

Related to editorconfig/specification#23 and editorconfig/specification#31
Fixes #44596
roslyn/src/Features/Lsif/Generator/.editorconfig
Lines 4 to 5 in 7464573
💭 I do notice that all cases we've found that seem to be affected involve a
dotnet_diagnosticline. 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#.