rust-lang / rls

Repository for the Rust Language Server (aka RLS)
Other
3.53k stars 257 forks source link

RLS crashes for some files containing non-ascii characters (Hebrew, specifically) #808

Open nbaraz opened 6 years ago

nbaraz commented 6 years ago

I don't know if it crashes for every non-ascii character, but it happened with a Hebrew character in one of my files. Doesn't seem too important to me (I typed the character by accident), but I have the traceback so I might as well report it.

I was editing the file with VSCode, with the rls-vscode plugin.

Traceback:

thread 'request-worker-0' panicked at 'byte index 8342 is not a char boundary; it is inside 'ק' (bytes 8341..8343) of `use arrayvec::ArrayVec;
use std::cell::{Ref, RefCell, RefMut};
use std::collections::HashMap;
use std::mem;
use std::ops::Deref;
use std::process::abort;
use std::rc::Rc;

use function::{self, Function};
use int;
use string;

#[derive(Debug, Clone)]
pub en`[...]', libcore/str/mod.rs:2257:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:207
   3: std::panicking::default_hook
             at libstd/panicking.rs:223
   4: core::ops::function::Fn::call
   5: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:403
   6: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:349
   7: rust_begin_unwind
             at libstd/panicking.rs:325
   8: core::panicking::panic_fmt
             at libcore/panicking.rs:72
   9: core::str::slice_error_fail
             at libcore/str/mod.rs:0
  10: core::str::traits::<impl core::slice::SliceIndex<str> for core::ops::range::Range<usize>>::index::{{closure}}
  11: racer::core::complete_from_file_
  12: racer::core::complete_from_file
  13: rls::actions::requests::<impl rls::server::dispatch::RequestAction for languageserver_types::request::Completion>::handle
  14: std::panicking::try::do_call
  15: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  16: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  17: std::panicking::try::do_call
  18: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  19: <rayon_core::job::HeapJob<BODY> as rayon_core::job::Job>::execute
  20: rayon_core::registry::WorkerThread::wait_until_cold
  21: rayon_core::registry::main_loop
  22: std::panicking::try::do_call
  23: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  24: <F as alloc::boxed::FnBox<A>>::call_box
  25: std::sys_common::thread::start_thread
             at /checkout/src/liballoc/boxed.rs:793
             at libstd/sys_common/thread.rs:24
  26: std::sys::unix::thread::Thread::new::thread_start
             at libstd/sys/unix/thread.rs:90
  27: start_thread
  28: clone
kngwyu commented 6 years ago

I'm sure it's racer's bug, similar to https://github.com/racer-rust/racer/issues/816 (but, I'm not sure it's same as this bug). Sometimes racer attempts to 'read UTF-8 string from its tail' for some speed up, but it's impossible so actually read bytes, and invalid access happens. @nbaraz Do you remember where the your cursor is when typing ק?(e.g. In a comment? In some statement(if/match/..)? Or in function call?)