Skip to content
This repository was archived by the owner on Dec 29, 2022. It is now read-only.

Problem finding sysroot #544

Closed
nrc opened this issue Nov 3, 2017 · 21 comments
Closed

Problem finding sysroot #544

nrc opened this issue Nov 3, 2017 · 21 comments
Labels

Comments

@nrc
Copy link
Member

nrc commented Nov 3, 2017

thread '<unnamed>' panicked at 'need to specify SYSROOT or RUSTC env vars, or rustc must be in PATH', src/libcore/option.rs:839:4

Reported in #450 (comment) by @cynecx

Might be an issue with the client setting up a bad environment, or it might be some bug in the RLS.

@cynecx Could you get a backtrace and try running with logging please? Details about logging are in https://github.com/rust-lang-nursery/rls/blob/master/debugging.md

@nrc nrc added the bug label Nov 3, 2017
@cynecx
Copy link

cynecx commented Nov 3, 2017

What I did:

export RUST_LOG=rls=debug
export RUST_BACKTRACE=1
open -a "Visual Studio Code"

Content of rls.log:

DEBUG:rls::server: Language Server starting up. Version: 0.122.0-nightly (48fd42f 2017-11-01)
DEBUG:rls::actions::post_build: reload analysis: "/Users/paul/dev/test2"
thread '<unnamed>' panicked at 'need to specify SYSROOT or RUSTC env vars, or rustc must be in PATH', src/libcore/option.rs:839:4
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: std::panicking::begin_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::option::expect_failed
  10: rls_analysis::loader::sys_root_path
  11: rls_analysis::raw::read_analysis_incremental
  12: <rls_analysis::AnalysisHost<L>>::reload_with_blacklist
  13: <rls_analysis::AnalysisHost<L>>::reload_from_analysis
  14: <rls::actions::post_build::PostBuildHandler<O>>::reload_analysis_from_memory

The project is a basic project with one source file, main.rs which contains:

mod internals {
    pub fn test() -> u32 {
        print!("")
    }
}

fn main() {
    internals::test();
}

What I've also noticed is, that it doesn't properly show that there is a type violation in fn test() (I guess, this is a different issue right?).

@Xanewok
Copy link
Member

Xanewok commented Nov 3, 2017

@cynecx do you have a RUSTC env var set?

@Xanewok
Copy link
Member

Xanewok commented Nov 3, 2017

I'm guilty of "simplifying" that logic and only now I realized I changed the semantics - previously it attempted to extract the sysroot using command at RUSTC and on any error (not only lack of RUSTC) it tried to do the same, only with rustc command. (Sorry @nrc!)

Maybe that's the root of the problem?

@cynecx
Copy link

cynecx commented Nov 3, 2017

@Xanewok Yes, it's currently set to RUSTC=/Users/paul/.cargo/bin/rustc, although, even without, it shouldn't be a problem, right?, because rustc is resolvable through the PATH env-variable.

@Xanewok
Copy link
Member

Xanewok commented Nov 3, 2017

Does /Users/paul/.cargo/bin/rustc --print sysroot work then? RLS tries to call a command at $RUSTC as the command (instead of rustc) if it's set to retrieve sysroot info, maybe that's the issue.

@cynecx
Copy link

cynecx commented Nov 3, 2017

@Xanewok Yes, it does work. The print sysroot command prints:

/Users/paul/.rustup/toolchains/nightly-x86_64-apple-darwin

@vorner
Copy link

vorner commented Nov 4, 2017

I have the same problem. I have rustc in path, I don't have RUSTC nor SYSROOT environment variables set (which is different from above). The log then contains some more backtraces, about mutex poisoning (I guess that just follows up).

The funny thing is, this doesn't really seem to matter much to RLS ‒ it works even after that backtrace. I wouldn't have noticed if I didn't look into the log for other reasons.

@GabrielMajeri
Copy link

Until this gets fixed, it seems hecaex's fix found in this comment still works.

Set the "rust.build_lib" setting to true in your settings.json and it stops throwing errors.

@oceanusxiv
Copy link

@GabrielMajeri unfortunately I just tried this, and at least using the latest nightly Rust this does not in fact stop it from throwing errors

@0x7CFE
Copy link

0x7CFE commented Nov 7, 2017

In my case setting rust.buildlib leads to another error:

thread 'main' panicked at 'byte index 16184 is not a char boundary; it is inside 'З' (bytes 16183..16185) of `                                                                                     
`[...]', /checkout/src/libcore/str/mod.rs:2232:4

@ChristophWurst
Copy link

I'm facing the same problem. RLS stopped working a few days ago, first discovered when I saw "RLS: working" as described in #548.

DEBUG:rls::server: Language Server starting up. Version: 0.123.0-nightly (9ad92e1 2017-11-06)
DEBUG:rls::actions::post_build: reload analysis: "/home/christoph/…"
thread '<unnamed>' panicked at 'need to specify SYSROOT or RUSTC env vars, or rustc must be in PATH', /checkout/src/libcore/option.rs:839:4
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:69
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:58
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:522
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:498
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:71
   9: core::option::expect_failed
             at /checkout/src/libcore/option.rs:839
  10: <rls_analysis::loader::CargoAnalysisLoader as rls_analysis::loader::AnalysisLoader>::search_directories
  11: rls_analysis::raw::read_analysis_from_files
  12: <rls_analysis::AnalysisHost<L>>::reload_with_blacklist
  13: <rls_analysis::AnalysisHost<L>>::reload_from_analysis
  14: <rls::actions::post_build::PostBuildHandler<O>>::reload_analysis_from_memory

The proposed workaround #544 (comment) did not solve the issue here.

RUSTC and SYSROOT were not set. However, rustc is in my PATH.

My setup:
racer 2.0.12
rls-preview 0.123.0-nightly (9ad92e1 2017-11-06)
rustc 1.23.0-nightly (ee2286149 2017-11-07)
Code 1.17.2 b813d12980308015bcd2b3a2f6efa5c810c33ba5
Arch Linux

@colibre
Copy link

colibre commented Nov 8, 2017

Substituting a compiled binary directly from the git repository solves the problem. There must be something wrong with the version rustup installs.

@ChristophWurst
Copy link

@colibre I can confirm that this "fix" works.

@mkpankov
Copy link

mkpankov commented Nov 8, 2017

For me, copying rls over borks rustup installation completely. rustup doesn't start because it doesn't find required libraries (like libsyntax-xxxx.so).

@king6cong
Copy link

@colibre works for me.

@bklooste
Copy link

Same problem here Ubuntu 17.2 ..not comfortable with the "fix" print sysroot is also correct .

@MaxBittker
Copy link

rustup update should fix this now

@cynecx
Copy link

cynecx commented Nov 12, 2017

@MaxBittker Nope. It's still spinnin'. Re-compiling rls and replacing the binary solves the issue.

EDIT: Stacktrace

thread '<unnamed>' panicked at 'need to specify SYSROOT or RUSTC env vars, or rustc must be in PATH', /checkout/src/libcore/option.rs:878:4
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:68
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:57
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:522
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:498
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:71
   9: core::option::expect_failed
             at /checkout/src/libcore/option.rs:878
  10: <rls_analysis::loader::CargoAnalysisLoader as rls_analysis::loader::AnalysisLoader>::search_directories
  11: rls_analysis::raw::read_analysis_from_files
  12: <rls_analysis::AnalysisHost<L>>::reload_with_blacklist
  13: <rls_analysis::AnalysisHost<L>>::reload_from_analysis
  14: <rls::actions::post_build::PostBuildHandler<O>>::reload_analysis_from_memory

@DSpeckhals
Copy link
Contributor

1.23.0-nightly (79cfce3d3 2017-11-12) has the RLS fixes in it. @cynecx, Can you run rustup run nightly rls --version and reply back with the output? Running that with 2017-11-12 should output:

rls-preview 0.123.0-nightly (015073b 2017-11-10)

If it does print that, it may be that your client (like VS Code) is using a non-working RLS version.

@cynecx
Copy link

cynecx commented Nov 13, 2017

That's strange, I've just run rustup update again and it seems it's working now.

@colibre
Copy link

colibre commented Nov 13, 2017

Works for me after updating.
Probably due to this getting closed rust-dev-tools/rls-analysis#119

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests