RLS isn't able to suggest anything from crates anymore, it suggests a set of random symbols instead

[Tomcc]

Hi,
First of all, I'm not an expert in RLS whatsoever so please excuse me if this turns out to be a setup issue on my side!

My setup is:

• Rust nightly
• Windows 10
• VSCode + official extension
• rls-preview from rustup

The issue is that well, autocomplete stopped working entirely 😄
Even in small ~400 lines single file projects , autocomplete only seems to work on std types and only in the first chained function call.
Basic stuff like suggesting .unwrap() after a result, or autocompleting anything from any crate I tried won't work.
What is worse is that rather than showing nothing like previous well behaved versions, RLS will show what looks like absolutely unrelated stuff!

As a test, I've reverted to nightly-2018-06-10 (called "old" below) and it shows a marked improvement.

Some examples:
old: shows nothing. Disappointing, but it's hard to deduce that that's a Vec<Receiver<String>> even by looking at it.
new:

I've tried the same in trivial cases eg. autocompleting an i32 and that will also show all kinds of weird macros.

old: shows correct autocomplete (socket(), raw, destroy())
new:

and even on a simple project:
old: correctly completes each section of this whole sequence:

    let r = Regex::from_str("test").unwrap();
    r.find("testtest").take().unwrap().end;

new:
it only shows this and then more random, wrong autocompletes from std if you go on.

For now I'll keep staying on the old version so RLS is not a nuisance, but there's a chance that this is a legit regression and you might want to know!

[kngwyu]

What's the output of rls --version?
rls-preview 0.130.5-nightly (e67fd48 2018-08-24)?
If so, I think there's a bug around #981

[Tomcc]

@kngwyu I've downgraded now so I don't know... I just ran rustup update before taking the screenshots, though. So the version is whatever is up right now.
Also, this has been a problem for at least a week and a few versions of RLS... definitely before Aug 24.
I run rustup update way too often for my own good :)

[kngwyu]

Can't reproduce with rls-preview 0.130.5-nightly (9e4d8d5 2018-08-10) but I can reproduce with rls-preview 0.130.5-nightly (e67fd48 2018-08-24).
So maybe it's because of #981 but I'm still debugging now.

[kngwyu]

Hmm but sometimes I can get completions even in current version...
So anyway I think there might be some problems around loading lockfile and call cargo::resolve_with_prev, though I haven't seen these kind of bug in racer itself.

[Tomcc]

From what I could see I think it gets worse if the project is bigger, especially if more dependencies are added. I'm not sure I've ever seen it working in the last few days though... but yeah, the behavior changed over time, it wasn't stable.

Oh, I often have 2 rust projects open in 2 different versions of VSCode! From a quick test though, leaving only one open didn't seem to help. Maybe it did, but a little?

[kngwyu]

I noticed if the project has no Cargo.lock rls causes an error

ERROR 2018-08-26T06:16:16Z: rls::actions: failed to fetch project model, using fallback: unable to get packages from source

since we don't allow it to write lockfile download package sources here https://github.com/rust-lang-nursery/rls/blob/master/src/project_model.rs#L47

@nrc @matklad
So... what approach should we select?
To generate lockfile when initing?
Or allow cargo to download deps and write lockfile?
For racer as a CLI tool, I allow it to run cargo metadata without --frozen if --frozen failed (https://github.com/racer-rust/racer/blob/master/src/racer/metadata.rs#L22)

[Tomcc]

@kngwyu I'm sure I always had Cargo.lock in all the affected project, though!

[kngwyu]

@Tomcc
Then... could you please run cargo metadata --format-version 1 in your project directory and restart your editor?
I believe it'll fix this issue.

[Tomcc]

So,

• I switched back to nightly

$ rls --version
rls-preview 0.130.5-nightly (e67fd48 2018-08-24)

• verified it's still broken (it is),
• ran this

$ cargo metadata --format-version 1
 Downloading fuchsia-zircon v0.3.3
 Downloading winapi-x86_64-pc-windows-gnu v0.4.0
 Downloading winapi-i686-pc-windows-gnu v0.4.0
 Downloading fuchsia-zircon-sys v0.3.3
... and a LOT of JSON ...

• restarted VSCode to make sure
• nope, still broken
  

[kngwyu]

Hmm I can't reproduce...

and have no idea now, sorry 😓

[GabrielMajeri]

I also have this issue. I get the rls::actions: failed to fetch project model, using fallback message. Is there any way to enable more logging for RLS?

Edit: I've removed the cargo-features = ["edition"] and edition = "2018" from my Cargo.toml, and now I don't get the error anymore. I take it RLS doesn't support Rust 2018 yet?

[nrc]

I take it RLS doesn't support Rust 2018 yet?

It should!

cc @matklad for rls::actions: failed to fetch project model, using fallback - could it be significant?

[kngwyu]

@GabrielMajeri

I take it RLS doesn't support Rust 2018 yet?

Since racer still needs extern crate statement, RLS can't complete crate name without extern crate.
I'm going to implement it soon, but it's not so straightforward(see racer-rust/racer#916)

[vonforum]

I take it RLS doesn't support Rust 2018 yet?

Having the same issue. Runnin rls with debug logging gives me this error

rls::actions: Encountered an error while trying to infer config defaults: ErrorMessage { msg: "the cargo feature `edition` requires a nightly version of Cargo, but this is the `nightly` channel" }
[..] failed to parse manifest at `[..]/Cargo.toml`

then it segfaults. Doesn't happen when I remove cargo-features = ["edition"] and edition = "2018"

[kngwyu]

@vonforum
It looks a different issue.
Could you open an another issue with rls version specified, please?

[Tomcc]

@kngwyu not sure what changed, but I've updated to rustc 1.30.0-nightly (6e0f1cc15 2018-09-05) and now everything works just fine.
Thanks!

[vonforum]

Same here, actually, everything works fine now. Seems the problem was related, after all.

[lebensterben]

@kngwyu not sure what changed, but I've updated to rustc 1.30.0-nightly (6e0f1cc15 2018-09-05) and now everything works just fine.
Thanks!

I'm redirected here from #1001

The same issue came back in later version of nightly compiler. Currently, Oct 22 2019, the latest working version is nightly-2019-13-x86_64_unknown-linux-gnu.

This bug persists for more than two weeks.
Shall we reopen this issue?