Rls: Formatting Stomping Over use Declarations

Created on 26 Apr 2019  ·  11Comments  ·  Source: rust-lang/rls

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"
bug P-high

All 11 comments

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.

Was this page helpful?
0 / 5 - 0 ratings