Better Rustfmt integration

[nrc]

RLS currently supports rudimentary Rustfmt integration. It could be improved a lot:

• currently errors if any sub-modules are present and the file is not saved to disk (stdin formatting fails if mod file not found rustfmt#562)
• we currently return the entire re-formatted file, it would be better to return the ranges modified and the new text (and also update the VFS with that) (blocked on API that returns the ranges modified rustfmt#1173)
• If there are no changes, don't change anything (Allow reformat to be a no-op #334). Rustfmt sort of has the facility to tell us this, but it is not exposed in the mode we need. Could be fixed by the diff approach, but might be easier to add as step towards that.
• allow formatting line ranges (Format ranges #333) (VSCode has a provider for this, but blocked on file_lines with a comment is broken rustfmt#1159)
• add a format-on-save option (apparently this should Just Work, need to document)
• take the indent-width hint from VSCode and pass it to Rustfmt (but don't override the user's setting, if set in rustfmt.toml)
• use the user's rustfmt.toml (Support formatting config via rustfmt.toml #331)
• Formatting adds newline at the end on file on each format (Formatting adds newline at the end on file on each format #282)
• Formatting seems to be broken? (Formatting seems to be broken? #242)

[KalitaAlexey]

@nrc,
Format On Save is built-in feature in Visual Studio Code.

[nrc]

And other issues:

• Formatting adds newline at the end on file on each format (Formatting adds newline at the end on file on each format #282)
• Formatting seems to be broken? (Formatting seems to be broken? #242)

Formatting is currently behind the 'unstable features' flag, we should fix at least the above two and rust-lang/rustfmt#562, before turning it on by default.

(copied into OP)

[nrc]

cc rust-lang/rust#42071

[nrc]

re formatting on save, @KalitaAlexey is correct. To do it you add the following to setttings.json:

"editor.formatOnSave": true

I feel like we should document this somewhere since it is not obvious.

[Xanewok]

@nrc This is editor/IDE-specific, so I think it'd be best to add it somewhere in rls_vscode (maybe under a section like Supported Features for VSCode?).

[Xanewok]

Also I've been thinking about the issue where Rustfmt fails to format the file and doesn't inform the user in a friendly way (you have to check the console for errors now).

We could implement continuous style check that's published with regular diagnostics (but with DiagnosticSeverity.Information severity; enabled via RLS settings?).

An example of how JetBrains IDE (PyCharm) shows style warnings:

On fail it could send a window/showMessage to a client with a message saying something along the lines of "Automatic formatting failed. Please resolve all the issues that require manual formatting first.".

Apart from solving the problem, where user doesn't know why the IDE isn't performing the auto-formatting, I think the opt-in continuous style check diagnostics is a neat idea on its own and would benefit users.

Also with regards to formatting on save - maybe we could make this feature editor-agnostic and provide format on save on the server side? I'll have to check if LSP allows for spontaneous (not explicitly requested) actions like that.

[nrc]

I've made formatting a whole file stable, formatting ranges is still unstable

[alexheretic]

Has there been any progress on range formatting? This is quite a common need when you don't own the project, you want to only format the bits you're touching.

[nrc]

Has there been any progress on range formatting?

Afraid not. It's one of the things I'd like to work on after 1.0

[norru]

Question: it doesn't look like rls loads .rustfmt.toml of the project unless rls has been started from the root directory of the project (ie the one containing .rustfmt.toml). Is this expected? I'm using the Corrosion Eclipse plugin; is it something that needs to be added to the plugin itself?

[nrc]

is it something that needs to be added to the plugin itself?

It should be handled by the RLS, not the plugin. This is probably a bug.

[norru]

Please ignore: I think it was a red herring due to an error in my .rustfmt.toml

[Sakari369]

Hey, thanks for all the work. Just wondering, should line formatting for ranges work or not ? Should it work by setting the unstable settings to true ? Seems the issues for those are closed, but cannot get it working by default at least with VScode and the Rust (rls) extension.

[alexheretic]

Range formatting doesn't work and it would be a very nice improvement to have this.

I'm not sure the status of this issue is being tracked very actively. Can rustfmt do this yet?

[Xanewok]

Technically it can, it's just gated behind unstable features flag for Rustfmt:

• tracking issue: file-lines  rustfmt#1514
• [unstable option] file_lines rustfmt#3397

[Xanewok]

Last remaining points (only return changed file range and return no-op if nothing changed) were addressed by #1385 and this works as expected. As such, I'm happy to close this tracking issue!

The last remaining thing to keep in mind is that range formatting is still gated behind unstable features but that's tracked upstream at rust-lang/rustfmt#3397.