RLS crashes in VSCode

[rnleach]

It just crashes on any project in Ubuntu 16.04. Chatted about it in #rust-tools with @jonathandturner and it seems it has something to do with latest rustup release.

[sophiajt]

rust-lang/rust#41900 just landed. With luck, this should roll out soon.

[sophiajt]

No luck... still seeing the crash even with the updated nightly

[FaultyRAM]

I'm also getting crashes with VSCode, but on Windows 10 Pro x64 1703.

thread 'main' panicked at 'unknown action', src\tools\rls\src\cmd.rs:78
stack backtrace:
   0:     0x7ff9866f502d - <std::time::SystemTimeError as core::fmt::Display>::fmt::h47b84a1015a24260
   1:     0x7ff986706491 - std::panicking::Location::line::had6a4712d93afde3
   2:     0x7ff986705f00 - std::panicking::Location::line::had6a4712d93afde3
   3:     0x7ff986706b01 - std::panicking::rust_panic_with_hook::hdc062cb76d0a48fb
   4:     0x7ff7956f7cb3 - <unknown>
   5:     0x7ff7957f0617 - <unknown>
   6:     0x7ff986709c41 - _rust_maybe_catch_panic
   7:     0x7ff98670733e - std::rt::lang_start::h19174a93e3fecee2
   8:     0x7ff796011dd8 - git_odb_object_id
   9:     0x7ff9bf5a2773 - BaseThreadInitThunk
thread '<unnamed>' panicked at 'Error reading from channel: RecvError', src\libcore\result.rs:859
[Error - 16:50:00] Connection to server got closed. Server will not be restarted.

[zimond]

My RLS is also crashing, but with a different message: messing field "experimental"

[Doaxan]

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ErrorImpl { code: Message("missing field `experimental`"), line: 0, column: 0 }', /checkout/src/libcore/result.rs:859
note: Run with `RUST_BACKTRACE=1` for a backtrace.
[Error - 5:10:26 PM] Connection to server got closed. Server will not be restarted.

With RUST_BACKTRACE=1

DEBUG:rls::server: Language Server Starting up
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ErrorImpl { code: Message("missing field `experimental`"), line: 0, column: 0 }', /checkout/src/libcore/result.rs:859
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:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:355
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:371
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:549
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:511
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:495
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:471
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:69
   9: core::result::unwrap_failed
  10: rls::server::parse_message
  11: rls::server::MessageReader::parsed_message
  12: rls::server::LsService::run
  13: rls::main
  14: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:98
  15: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:433
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:56
  16: __libc_start_main
  17: <unknown>

[Enet4]

I'm replicating some information from editor-rs/vscode-rust#229, because I've looked into the matter and it might not be more an issue with the Rust extension than I had initially thought.

The RLS type definition ClientCapabilties was recently changed from a generic JSON value to a JSON object with the fields "workspace", "textDocument" and "experimental", in accordance to the language server protocol. Although we could just make sure that the extension always provides the three fields, the specification on initializing requests explicitly states that "a missing property should be interpreted as an absence of the capability", and not as a problem with the client. Would it be sufficient if we gave these fields default values when deserializing? :)

Edit: There's an issue over at gluon-lang/lsp-types#14 already.

[Marwes]

0.9.0 (with the required fixed) of languageserver-types is now published

[kmod-midori]

When will the fix be available in rustup?

[Enet4]

Since nightly builds are updated nearly daily (upon new passing changes in the master branch) , it should become available tomorrow. Meanwhile, you can build RLS from source yourself.

[kmod-midori]

It crashes...