Skip to content
This repository has been archived by the owner on Nov 18, 2022. It is now read-only.

RLS doesn't support RUSTC_WRAPPERs #460

Open
mythmon opened this issue Dec 1, 2018 · 11 comments
Open

RLS doesn't support RUSTC_WRAPPERs #460

mythmon opened this issue Dec 1, 2018 · 11 comments
Labels
bug rls Issue related to the RLS itself rather than the extension

Comments

@mythmon
Copy link

mythmon commented Dec 1, 2018

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.

@marmistrz
Copy link

This error persists in 0.5.1, which completely breaks the extension.

@ejpcmac
Copy link

ejpcmac commented Dec 11, 2018

I’m 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’s strange, though.

@marmistrz
Copy link

For me the error was gone after updating to 0.5.2

@ejpcmac
Copy link

ejpcmac commented Dec 11, 2018

I’m still facing the issue with rls-vscode 0.5.3.

@heilhead
Copy link

I got it fixed by disabling rust.all_features in the VS Code settings. (0.5.3 windows)

@dwaynebradley
Copy link

dwaynebradley commented Dec 20, 2018

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...

@tangmi
Copy link

tangmi commented Jan 21, 2019

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: rust-lang/rls#703, which had a workaround in rls 1.33.0.

@dwaynebradley
Copy link

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.

@Xanewok Xanewok added bug rls Issue related to the RLS itself rather than the extension labels Apr 7, 2019
@Xanewok Xanewok changed the title Could not compile <crate> in Cargo.toml RLS doesn't support RUSTC_WRAPPERs Apr 7, 2019
@brundonsmith
Copy link

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.

@brundonsmith
Copy link

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"}

@brundonsmith
Copy link

Bizarrely, when I change the notify version to 3.0.0, the problem also goes away.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug rls Issue related to the RLS itself rather than the extension
Projects
None yet
Development

No branches or pull requests

8 participants