Fix up bugs in parsing special chracters in EditorConfig

[captainsafia]

Resolves issues like dotnet/aspnetcore#33832 and #51692.

Follow-up to #52515.

Changes in this PR

1. Avoid using the WriteLinesToFile task to write the editor config to disk and write to disk inside GenerateMSBuildConfigEditor task.

Moving from C# to MSBuild to EditorConfig causes a lot of weird issues when writing editorconfigs with special characters mostly due to MSBuild's behavior in certain scenarios.

• The editorconfig format uses backslashes to escape characters but MSBuild automatically converts backslashes to forward slashes which breaks writing special characters to disk.
• Semicolons aren't interpretted correctly when processed in MSBuild since they are treated as item separators.
• Probably some other weirdness that I'm not accounting for here.

Given all this, I think it makes sense to move the file writes to inside the GenerateMSBuildConfigEditor task to avoid issues that come up because of the interop between C# strings, MSBuild strings, and editorconfig's requirements.

2. Escape section names before comparing source paths with the associated section names in GetSectionFromSource.

Validations

• Local unit tests
• Ran the changeset against the https://github.com/dotnet/website project which contains an AdditionalText that falls victim to this bug (ref)
• Ran the changeset against the Razor source generator integration tests

[captainsafia]

@dotnet/roslyn-compiler Any chance I can get a review on this? This is blocking dotnet/website adopting the new Razor source generator and has been reported by a few customers in the previews.

[cston]

", result);

Are we verifying the contents written to FileName?

---

Refers to: src/Compilers/Core/MSBuildTaskTests/GenerateMSBuildEditorConfigTests.cs:33 in 08a8780. [](commit_id = 08a8780, deletion_comment = False)

[cston]

public

private or internal?

[cston]

}

Consider adding Assert.False(configTask.WriteMSBuildEditorConfig());

[cston]

I was hoping to test that WriteMSBuildEditorConfig() did not update the file if the contents were already correct, but it looks like It looks the method returns true in either case.

Should we add an out bool updated parameter that indicated whether the file was modified, and check that value?

[cston]

sb.Append(lexer.CurrentCharacter)

Do we ever hit this code path? I may be misreading the Lex() method, but it looks like CurrentCharacter is the character after the special character in this case. Is that expected here? #Closed

[captainsafia]

Yeah, you're right. This path never gets hit. I'm not sure why I had this in the first place (perhaps something came up when I was doing the end-to-end testing with the dotnet/website repo), but it's not needed. CanGetSectionsWithSpecialCharacters still passes without this.

[captainsafia]

Can this be merged or are there other things to sort out? Hoping to ship this fix alongside rc1.

[cston]

Thanks @captainsafia for fixing this.