Roslyn: Support `end_of_line` and `insert_final_newline` settings in `dotnet-format`

[warrenseine]

Version Used: Git master (c4bd5b23cbcc0182f617c37dc09837bb565e06c7)

Steps to Reproduce:

1. Create a project with a simple class
2. Indent with 4 spaces, set line endings to LF, and remove last newline.
3. Add an .editorconfig file with the following configuration:

[*.{cs,csx,vb,vbx}]
indent_size = 2
end_of_line = crlf
insert_final_newline = true

Expected Behavior:
2-space indent, new line at the end of the class and CRLF line endings.

Actual Behavior:
Just 2-space indent.

While dotnet-format output changes depending on EditorConfig settings like indent_size, it doesn't seem to respect end_of_line or insert_final_newline. I don't really understand why because Roslyn apparently reads these settings.

Where should I start looking if I wanted to contribute support for these?

I've seen feature requests like https://github.com/dotnet/roslyn/issues/20356 and https://github.com/dotnet/roslyn/issues/18934, but both target Roslyn (not dotnet-format itself), and were closed.

Thanks!

[jmarolf]

@warrenseine the problem is that these "universal" options are handled by VS itself. I agree it would be beneficial for dotnet-format to support this.

[sharwell]

Interesting. Note that dotnet-format just runs the formatter from Roslyn, so anything Roslyn handles would automatically be supported by dotnet-format as well.

[warrenseine]

I understand that dotnet-format is just a CLI for Roslyn formatter. What I meant is that there already are some Roslyn analysers leveraging these options. See https://github.com/dotnet/roslyn/blob/defeca5d0e44915fc978cfd93d3de2e4a6d0dbf4/src/Features/Core/Portable/CodeRefactorings/MoveType/AbstractMoveTypeService.MoveTypeEditor.cs#L136 for instance.

[sharwell]

Design review conclusion: we would accept a proposal to update the whitespace formatter (used by Format Document) to adhere to the end_of_line and insert_final_newline settings, if specified in .editorconfig. If the settings are not specified, the formatter should retain the behavior it has today (leave the end of file as-is, and needs investigation to determine the current end-of-line behavior in cases where files contain mixed line endings). The dotnet-format tool uses this formatter, so it would automatically pick up the new behavior.

[warrenseine]

I just tested again and I can't reproduce anymore. Both parameters are correctly interpreted. Thanks!