Format document does not honor final newline

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

1. Launch Visual Studio 2022
2. Create or load a new C# project
3. Add a .editorconfig file to the project
4. Open the .editorconfig and ensure that "Insert Final Newline" is checked.
5. Open a C# file in the project
6. Go to the end of the file and remove any trailing newline.
7. Format document

Result: The document does not end with a newline.

Expect: A newline should be added.

---

Original Comments

Feedback Bot on 5/31/2023, 08:57 PM:

(private comment, text removed)

---

Original Solutions

(no solutions)

[sharwell]

This property is already supported by the editor (#20356), but not by Format Document, so it only applies when a document is saved. This is a feature request to also support it in the Roslyn formatter.

[pharring]

My broader scenario was this:

1. Open a C# project with "Insert final newline" enabled in .editorconfig
2. Open one of the source files (e.g. a class in a namespace) and observe that it has a final newline.
3. Toggle the namespace scope. i.e. put the caret on the namespace line, bring up the lightbulb menu and select "Convert to block scoped namespace" or "Convert to file scoped namespace"

Result: Observe that the trailing newline has been removed. Expect: The fixer for namespace scope should observe the "Insert final newline" setting and, in this case, preserve the final newline.

Is this a separate issue, or would it be covered by "Format Document"?

[sharwell]

The fixer for namespace scope should observe the "Insert final newline" setting

I would expect this to already be fixed as part of #59728. The fixer for namespace scope should not follow the "Insert final newline" setting. It should preserve the state of the end of the document exactly as it was (the refactoring will leave the document with a trailing newline if and only if the document already had a trailing newline).

[pharring]

Well, I see that converting to file scoped namespaces correctly preserves trailing whitespace. However, converting (back) to block namespace removes it. I'd expect these two operations to round trip perfectly -- at least on straightforward (non-contrived) examples. So, I think there's still a bug.

Experimenting a little, it appears the trailing whitespace is removed only if there's nothing off the end of the namespace. If you have anything following the logical end of the namespace (e.g. a comment or a directive like #endregion or #endif), then that's preserved along with any leading/trailing whitespace.

[sharwell]

@pharring I submitted #68428 to fix the behavior of the refactoring you mentioned.

[woeterman94]

Has this been resolved? Seem that

insert_final_newline = true trim_trailing_whitespace = true

Is still not working

[sharwell]

insert_final_newline = true

This property is currently handled by the editor at the time the file is saved. The Roslyn formatter does not do anything with this property.

trim_trailing_whitespace = true

This property ignores the semantics of the C# language, and can change the meaning of code by altering whitespace within verbatim and raw strings. The Roslyn formatter will never honor this property, and it's highly recommended to set the value to false to ensure that other tools also do not incorrectly alter the contents of source files.

In addition, the Roslyn formatter is always expected to remove insignificant whitespace at the end of lines. Currently there are some cases where it fails to do so. We would likely accept a pull request to correct these situations.