The only thing that this extension seems to do is show an single error that covers every line in my Cargo.toml that says "Could not compile
The problems panel shows this:
Could not compile `rand_core`.
process didn't exit successfully: `/home/mythmon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rls rustc --crate-name rand_core /home/mythmon/.cargo/registry/src/github.com-1ecc6299db9ec823/rand_core-0.3.0/src/lib.rs --color never --crate-type lib --emit=dep-info,link -C debuginfo=2 --cfg 'feature="alloc"' --cfg 'feature="std"' -C metadata=b6d594d63c2dd510 -C extra-filename=-b6d594d63c2dd510 --out-dir /home/mythmon/src/advent-of-code/target/rls/debug/deps -L dependency=/home/mythmon/src/advent-of-code/target/rls/debug/deps --cap-lints allow --error-format=json --sysroot /home/mythmon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu` (exit code: 1)
Running that command manually reports
Unknown argument 'rustc'. Supported arguments:
--version or -V to print the version and commit info
--help or -h for this message
--cli starts the RLS in command line mode
No input starts the RLS as a language server
This seems to me that I have a version incompatibility between RLS and rls-vscode. I've updated both (and VS Code itself). The command rls --version reports rls-preview 1.31.6 (daa138c 2018-11-20). I have version 0.4.10 of rls-vscode.
It would be nice to fix this problem, and also to be able to detect such version incompatibilities in the future.
This error persists in 0.5.1, which completely breaks the extension.
I鈥檓 facing this issue too. As a temporary workaround, you can run in a terminal:
$ rls --cli
Wait for the build to terminate, then hit ^C. RLS should then work in VSCode. That鈥檚 strange, though.
For me the error was gone after updating to 0.5.2
I鈥檓 still facing the issue with rls-vscode 0.5.3.
I got it fixed by disabling rust.all_features in the VS Code settings. (0.5.3 windows)
I just updated to VSCode 1.30.1. After that, I uninstalled the rust extension, reloaded VSCode, then reinstalled the rust extension and the errors went away for me.
Well...the issue is back again...
I'm on Windows 10, VS Code 1.30.2, rust-lang.rust 0.5.3, rls 1.31.6, and Stable rustc 1.32.0. I previously had an old install of Rust/rls set up (I think it was from before rls was even a toolchain component in rustup?) and the RUST_SRC_PATH environment variable set up (if it matters).
Running rls --cli simply showed the same error as VS Code.
Not sure if this will work for everyone, but I was able to fix this issue by doing a complete removal of all rust toolchains, rustup, and deleting and leftovers (e.g. RUST_* environment variables, .cargo, .mutlirust, .rustup, etc folders), then reinstalling everything. After installing racer, all intellisense is back in VS Code and I'm a happy camper.
Edit: Tried this on macOS (but otherwise same versions of everything else) and am still running into the same issue there... I can't think of any specific reason why macOS would be different here...
Edit 2: It seems using sccache was the cause of the issue for me. There's an issue open here: https://github.com/rust-lang/rls/issues/703, which had a workaround in rls 1.33.0.
Just to confirm that sccache was my issue as well. I removed the export RUSTC_WRAPPER=sccache line in my .profile and I'm not seeing the error any longer.
I get the same outcome with a slightly different error message in rls --cli:
thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:620:9
Any news on this bug? The problem only seems to happen on mine when I add notify = "4.0.0" to my dependencies. I had rand in there before and it worked fine, and when I remove notify it's fine. Even with notify, cargo build appears to work fine.
More details:
thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:620:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
1: std::sys_common::backtrace::_print
2: std::panicking::default_hook::{{closure}}
3: std::panicking::default_hook
4: rustc::util::common::panic_hook
5: std::panicking::rust_panic_with_hook
6: std::panicking::begin_panic
7: rustc_errors::Handler::bug
8: rustc::util::bug::opt_span_bug_fmt::{{closure}}
9: rustc::ty::context::tls::with_opt::{{closure}}
10: rustc::ty::context::tls::with_context_opt
11: rustc::ty::context::tls::with_opt
12: rustc::util::bug::opt_span_bug_fmt
13: rustc::util::bug::bug_fmt
14: rustc::ty::context::TypeckTables::node_type::{{closure}}
15: rustc::ty::context::TypeckTables::expr_ty_adjusted
16: rustc_save_analysis::SaveContext::get_expr_data
17: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_expr
18: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O>>::process_assoc_const
19: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_item
20: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O>>::process_method
21: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_item
22: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_item
23: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_mod
24: <rustc_save_analysis::DumpHandler<'a> as rustc_save_analysis::SaveHandler>::save
25: rustc::dep_graph::graph::DepGraph::with_ignore
26: rustc_driver::enable_save_analysis::{{closure}}::{{closure}}
27: rustc_driver::enable_save_analysis::{{closure}}
28: rustc::dep_graph::graph::DepGraph::with_ignore
29: rustc_driver::driver::compile_input::{{closure}}
30: <std::thread::local::LocalKey<T>>::with
31: rustc::ty::context::TyCtxt::create_and_enter
32: rustc_driver::driver::compile_input
33: rustc_driver::run_compiler_with_pool
34: <scoped_tls::ScopedKey<T>>::set
35: rustc_driver::run_compiler
36: <scoped_tls::ScopedKey<T>>::set
query stack during panic:
end of query stack
{"message":"aborting due to previous error","code":null,"level":"error","spans":[],"children":[],"rendered":"error: aborting due to previous error\n\n"}
Bizarrely, when I change the notify version to 3.0.0, the problem also goes away.
Most helpful comment
I鈥檓 still facing the issue with rls-vscode 0.5.3.