rust-analyzer: Incremental text sync panics
0ms - infer:wait (319 calls)
2ms - parse_macro_query (64 calls)
thread 'main' panicked at 'assertion failed: self.is_char_boundary(n)', /home/matklad/.rustup/toolchains/beta-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/macros/mod.rs:34:9
stack backtrace:
21ms - handle_inlay_hints
20ms - inlay_hints
6ms - Semantics::analyze2 (307 calls)
0ms - crate_def_map:wait (42 calls)
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
at src/libcore/panicking.rs:54
14: alloc::string::String::replace_range
15: rust_analyzer::main_loop::apply_document_changes
16: ra_vfs::Vfs::change_file_overlay
cc @lnicola, not sure how to repro this, but I’ve seen this a couple of times.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 32 (32 by maintainers)
Commits related to this issue
- Merge #4276 4276: Don't count start of non-ASCII characters as being inside of them r=matklad a=lnicola I'm still not sure that `utf16_to_utf8_col` is correct for code points from Supplementary Plan... — committed to rust-lang/rust-analyzer by bors[bot] 4 years ago
- Merge #4278 4278: Log panics in apply_document_changes r=matklad a=lnicola This doesn't necessarily help (because of https://github.com/rust-analyzer/rust-analyzer/issues/4263#issuecomment-623078531... — committed to rust-lang/rust-analyzer by bors[bot] 4 years ago
- Merge #6036 6036: Don't re-read open files from disk when reloading a workspace r=kjeremy a=lnicola Fixes #5742 Fixes #4263 or so I hope. Co-authored-by: Laurențiu Nicola <lnicola@dend.ro> — committed to rust-lang/rust-analyzer by bors[bot] 4 years ago
For typing
xafter// 💔in💔I getVS Code gives
I think Emacs sends codepoints coordinates and vscode uses utf16? Feels like a bug in Emacs to me 😃
I wish we can just respond with an error to the editor in this case, but, well, LSP uses notifications… Note to self: never design RPC mechanism with one-way messages.