index out of bounds for crates/ra_ide_db/src/line_index.rs

[Dushistov]

Seems unrelated to #5366 because of backtrace completely different.
Happens during editing close source project

[ERROR rust_analyzer::main_loop] duplicate DidOpenTextDocument: /home/evgeniy/projects/something/src/lib.rs
thread '<unnamed>' panicked at 'index out of bounds: the len is 2 but the index is 18', crates/ra_ide_db/src/line_index.rs:102:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1069
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1504
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:218
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:511
  11: rust_begin_unwind
             at src/libstd/panicking.rs:419
  12: core::panicking::panic_fmt
             at src/libcore/panicking.rs:111
  13: core::panicking::panic_bounds_check
             at src/libcore/panicking.rs:69
  14: ra_ide_db::line_index::LineIndex::offset
  15: rust_analyzer::handlers::handle_code_action
  16: <F as threadpool::FnBox>::call_box
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[lnicola]

Did you ever type a non-ASCII character in that file?

Yes, it's unrelated to #5366.

[Dushistov]

Did you ever type a non-ASCII character in that file?

Yes, it has not-english comments (utf-8), but the comments was far above of last editing region.
rust-analyzer crashes continuously after the first crash.
After I restart all from scratch and try to reproduce my last activity: I moved function from old-lib.rs to lib.rs
nothing crashes, so have no idea how to reproduce problem.

[lnicola]

There are two possibilities here:

• we've recently added incremental text synchronization, where the LSP client (editor) sends only the changed text instead of the full file; this is more efficient, but can lead to issues if we get desynchronized
• LSP positions are in UTF-16 code points, but we store strings as UTF-8; we might count bytes incorrectly during this conversion

If you find a file where RA crashes reliably, it's probably the second issue. If happens only seldom, it might be either of them. You can disable incremental sync by setting the RA_NO_INCREMENTAL_SYNC environment variable -- you'll have to run your editor from the terminal or change a .desktop file for that to propagate, at least on Linux.

[lnicola]

I assume your comments are in Cyrillic (and not e.g. emoji)? The difference is that Cyrillic characters have only one code point.

[Dushistov]

I assume your comments are in Cyrillic (and not e.g. emoji)?

Yes, Cyrillic.

[jonas-schievink]

Hmm, this happens a lot on rust-analyzer as well, but without any non-ASCII characters

[lnicola]

This might actually be a duplicate of #4266, both are from handle_code_action.