-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Index out of bounds panic in line index #10138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I think I was able to reproduce it. I wasn't commenting the code, I was deleting it. If you try deleting lines 547 to 1317 of |
Ugh, this looks bad. And it's not that easy to reproduce, I can't trigger it. |
Are you using VS Code or coc.nvim? |
I'm using VS Code |
It does not always work, but generally if a save the file recently with |
Maybe you could try to get a complete LSP trace by setting If this still works, you should get a trace of every LSP message between Code and the server. We don't have a replay tool yet, but in principle you should be able to reproduce the issue by replaying that log. The thing I'm worried about is that the server and client view of the file gets desynchronized, so it's not the edit you're making, but the full edit history in that session. Or maybe it's something else. Are you interacting with the code lenses? I think |
Not a file, a JSON map with the two keys, one to enable logging and one to redirect the logs to a file (otherwise they spam the Code console). |
is this ok? In my workspace settings I suppose. {
"RA_LOG=lsp_server": ["debug", "error"],
"RA_LOG_FILE": "/Users/tomas/Documents/sqlparser-rs/output"
} I can't get it to work. |
@tvallotton I think the right format is:
|
Ok so I just pushed the logs at output.txt. If you need anything else just let me know. |
Yeah, it looks fine, but it's very short and I think it contains no edits. I would have expected something in the range of tens of MBs, with LSP being so verbose. On the other hand, I'm not sure we're flushing the log, so the last line or two might be truncated. |
One hypothesis I have is maybe the clined indeed sends But in general I think I see a bug here -- we shouldn't assume that between list/resolve calls the state of world doesn't change. We shouldn't be storying text ranges in the resolve data at all, for that matter. Instead, we should use the pattern we employ for code actions and completion -- re-run the same query, and use id of the result as data. |
I'm not sure if this is relevant, but I have been getting errors when using rust-analyzer with VS Code, lately. I can't offer any backtraces but I can report that this was with nightly Rust (fully updated) as the default, and I was using the crate inline-python within the code, which relies on nightly Rust. rust-analyzer was also having trouble with macro calls in this crate so I had also disabled checking for macro-errors. Changing back to stable Rust and removing this inline-python dependency appears to have removed any backtraces in the analyzer. Hope this helps. I can also try and capture some backtraces if desired. |
Ran into this as well again today, for me it wasn't the code lenses trigger it but codeActions/assists instead.
|
This comment has been minimized.
This comment has been minimized.
#11182 silences the panic, but the main problem described here still persists |
11182: fix: don't panic on seeing an unexpected offset r=Veykril a=dimbleby Intended as a fix, or at least a sticking plaster, for #11081. I have arranged that [offset()](https://github.com./rust-analyzer/rust-analyzer/blob/1ba9a924d7b161c52e605e157ee16d582e4a8684/crates/ide_db/src/line_index.rs#L105-L107) returns `Option<TextSize>` instead of going out of bounds; other changes are the result of following the compiler after doing this. Perhaps there's still an issue here - I suppose the server and client have gotten out of sync and that probably shouldn't happen in the first place? I see that #10138 (comment) suggests what sounds like a more substantial fix which I think might be aimed in this direction. So perhaps that one should be left open to cover such things? Meanwhile, I hope that not-crashing is a good improvement: and I can confirm that it works out just fine in the repro I have at #11081. Co-authored-by: David Hotham <[email protected]>
Closing this for now, we've made some changes here again so this is likely a stale issue |
Rust analyzer panicked while commenting some code. I haven't been able to reproduce the issue, but I decided to give you the output just in case. I was commenting either the
ast::Statement
enum or its Display implementation. If it helps the code I had can be found at https://github.com./tvallotton/sqlparser-rs/tree/rust-analyzer-panic.The text was updated successfully, but these errors were encountered: