Whitespace-only lines are removed rather than trimmed on format

[Rua]

When using the formatting tool (ctrl+shift+c), if there are any lines that consist only of whitespace, the entire line is removed. E.g. starting with

fn foo() {}

fn main() {}

with spaces or tabs on the second line, you end up with

fn foo() {}
fn main() {}

What should happen instead is that the trailing whitespace is removed, but the line isn't. Normal Rustfmt doesn't have this problem, so it seems to be an issue specific to the Atom plugin.

[alexheretic]

I can't reproduce this with a simple attempt. ide-rust ---- ctrl shift c ---> rls will ask rls to call rustfmt. It should act exactly like cargo fmt.

Can you confirm you're comparing stable rls to stable rustfmt? After that we'd need to nail down some good steps to reproduce this. Overall it's quite unlikely an issue is clientside as ide-rust/atom-languageclient will just do what rls directs, so if there is a discrepancy I'd say it's probably an rls bug.

[Rua]

I am just using whatever was installed by the plugin, I can't see what's going on underneath. I'm not using nightly Rust.

[alexheretic]

Ok, that should mean stable rls if you installed it recently. I presume you're running rustfmt with cargo fmt to compare behaviour?

If they act differently it's a bug, it's just a case of figuring out where & why. Do you have rustfmt.toml config files for this project, or in any parent dirs?

[Rua]

I'm using cargo fmt -- --check, so that it shows me in advance what the result will be. It shows the removal of the whitespace line and the addition of a new blank line in its place. I have rustfmt.toml in the crate root, containing only

hard_tabs = true

However, the bug happens even in a blank project that has no such file.

[alexheretic]

Ok, just to check are your versions thus:

$ rls -V
rls 1.38.0 (7b0a20b 2019-08-11)

$ cargo -V
cargo 1.38.0 (23ef9a4ef 2019-08-20)

Also what OS are you using? And are you using the latest ide-rust & atom versions?

[Rua]

I get exactly that output. Running Linux Mint 19.2, Atom 1.40.1 (installed via package manager), ide-rust 0.21.0.

[alexheretic]

Ok good. Next step is to debug the language server messages. Enable debug output, then set your code to

fn foo() {}


fn main() {}

ctrl shift c gives RLS textDocument/formatting response:

[{"range":{"start":{"line":2,"character":0},"end":{"line":3,"character":0}},"newText":""}]

which for me correctly removes line 2

fn foo() {}

fn main() {}

If I run it again RLS responds with empty [] json, ie do nothing, also correct.

[Rua]

Yes, that's all looking ok. But if I have only one empty line, and put a space on the second line, I get:
[{"range":{"start":{"line":1,"character":0},"end":{"line":2,"character":0}},"newText":""}]

[alexheretic]

If you have 2 blank lines you mean?

I thought the issue was

fn foo() {}

fn main() {}

turning into

fn foo() {}
fn main() {}

(which I can't yet reproduce)

[Rua]

That is the issue, but only if on the second line there is whitespace. So one line of code, one line with just whitespace, then another line of code.

[jamart28]

I am also encountering this issue. To try and help clarification I provided pictures below:

formats to:

whereas this:

formats correctly to

All cursors on blank lines are placed at the end of the line and the project this is being done with does not use a rustfmt.toml since I was using default formatting. cargo fmt does indeed format the file correctly but allowing atom to reformat the file through ctrl+shift+c or through saving (I have the format on save option on).

[jamart28]

Looking through the logs I now realize that it is handling the issue shown above by starting on the line with the whitespace and ending on the next line but replacing it with "" instead of what presumably should be "\n". Does this mean it is an rls issue? Is there a way to get similar output from rustfmt or cargo fmt to see if it differs? @alexheretic

[alexheretic]

Thanks @jamart28 I can reproduce this now. Looks like an rls issue to me: rust-lang/rls#1642

[alexheretic]

ide-rust has moved to using rust-analyzer instead of RLS. This issue seems fixed there.