Vscode-rust: RLS doesn't support `RUSTC_WRAPPER`s

Created on 2 Dec 2018  路  11Comments  路  Source: rust-lang/vscode-rust

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 crate changes every time I restart VS Code, but the problem stays the same.

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.

bug rls

Most helpful comment

I鈥檓 still facing the issue with rls-vscode 0.5.3.

All 11 comments

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.

2019-01-01

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.

Was this page helpful?
0 / 5 - 0 ratings