Hello,
I'm getting an annoying bug with the rustfmt bundled within RLS. When the formatting tries to reorder "use" declarations, it stomps over other use declarations!
Artificial Example:
Before:
use num_derive::FromPrimitive;
use num_traits::FromPrimitive;
use core::any::Any;
After:
use core::any::Any;
use num_traits::FromPrimitive;
This problem wasn't happening in my previous nightly version (mid March version - I've lost the exact version). It only started happening when I had recently updated my nightly. Furthermore, this does _not_ happen when I format through the command line via "cargo fmt". It also does not happen on the stable branch.
I'm using VSCode with the RLS extension (version 0.6.1). "rust-client.disableRustup": true is set in my workspace configuration.
Rustc version: rustc 1.36.0-nightly (3991285f5 2019-04-25)
Rls version: rls 1.36.0 (20e3268 2019-04-21)
rustfmt.toml:
edition = "2018"
version = "two"
I can reproduce this, too.
Just got this in Corrosion, same rls version as the OP.
In general, formatting seems to have regressed a lot since "differential" formatting was implemented; there are a few other issues which sprung up recently.
@norru did you experience anything else besides the tabsize regression?
From a quick glance it seems the stomping occurs when there is no change in indentation - if it's missing or the indent is too big the stomping does not occur.
@Xanewok
Would you be so kind as to remind me what the tabSize issue was? I've run into a tabSize issue but it turned out to be an IDE-specific one, and probably expected behaviour. EDIT: is it https://github.com/rust-lang/rls/issues/1438?
This other issue is particularly annoying right now: https://github.com/rust-lang/rls/issues/1397. Also, I've spotted a few instances of the "character":18446744073709551615 bug after it was marked fixed. I've reported them somewhere but I can't find the specific issue right now.
{"jsonrpc":"2.0","id":"56","result":[{"range":{"start":{"line":5,"character":0},"end":{"line":5,"character":18446744073709551615}},"newText":"use gtk::traits::*;"}]}
It's not just use declarations, it's just about anything that gets in the way when things are being reordered.
For example, this:
use std::fmt;
use std::error;
fn main() {
println!("Hello, world!");
}
becomes this: (note the blank line at the top as well)
use std::error;
use std::fmt;
println!("Hello, world!");
}
As already noted by others, this doesn't happen with rustfmt when it's run on its own from the same nightly version.
I've also seen it eat things when changing indentation.
This:
fn foo() {
{
println!("foo");
}
}
fn bar() {
println!("Hello, world!");
}
Becomes this:
fn foo() {
{
println!("foo");
}
}
println!("Hello, world!");
}
For whatever reason, the inner brackets in fn foo() are necessary to trigger the behavior.
$ rustfmt --version
rustfmt 1.2.2-nightly (5274b49 2019-04-24)
$ rls --version
rls 1.36.0 (20e3268 2019-04-21)
$ rustup show
...
active toolchain
----------------
nightly-2019-05-04-x86_64-unknown-linux-gnu (default)
rustc 1.36.0-nightly (a3404557c 2019-05-03)
Still happening with nightly, versions:
$ rls --version
rls 1.36.0 (5b8e99b 2019-05-01)
$ rustc --version
rustc 1.36.0-nightly (7158ed9cb 2019-05-15)
It's fixed in RLS master, it just needs to make its way to the main rust repository. If you'll notice, the rls version you're using is from 2019-05-01 and the issue was fixed 2019-05-14 (ish).
Ok, if it as expected, I'll just wait a bit longer :)
Is there any chance of getting this fixed in the 1.35 branch?
No chance for the current stable unfortunately but I'd say this might have a shot to make it to beta.