Invalid offset -32603 when editing an empty .rs file #17289
Labels
Comments
|
I had the same issue today using Mason+Lspconfig+RustAnalyzer as installed by Mason. I tried I'm not sure what the root cause of this error is, but following this Stack Overflow link, I tried I no longer had the terminal |
|
I ran that command and it also showed that error about the toolchain not being installed. However even after installing it the situation is the same. |
|
You're correct, I mistakenly thought the problem was resolved. I am having this problem as well. |
|
This makes me believe that it might be an mason/lspconfig bug? (we should probably tell the invalid offset in the error message here) |
|
Happens to me too in Neovim with Mason + Lspconfig on macOS |
|
Can you check whether this occurs with a previous rust-analyzer version? It's not clear if this is a rust-analyzer bug or maybe a change in mason/lspconfig that surfaced this. |
It happens for quite a while, in multiple Rust Analyzer versions. |
|
@yuvaldolev how do you install it, using rustup, or from source / GitHub releases? |
I installed rust-analyzer using Mason (Rust itself is installed using Rustup but not rust-analyzer). BTW this error seems to happen in other times than just editing an empty file. It happens to me once in a while when coding in Neovim, which is a real bummer as I have to reopen Neovim and lose the state of my project (doing LspRestart doesn't solve this... I must reopen Neovim to fix it). |
|
I am still experiencing this issue. I've noticed that it also rarely happens when the buffer is not empty if I start editing it while rust analyzer is still indexing files. |
|
In what r equest handler is this happening? The logs should tell that. I am unsure what the cause here is, given it only seems to occur for this specific editor setup |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
the offset panic occuring sporadically for some requests is known (unsure iif we have that tracked rn), this issue is talking about it occuring constantly under a certain setup |
I'm using the same setup (Mason + Lspconfig on macOS) and here are my LSP logs when the error occurs. The error can be triggered by doing the following:
|
bors
added a commit
that referenced
this issue
Jun 5, 2024
minor: Add debug info to invalid offset error cc #17289
lnicola
pushed a commit
to lnicola/rust
that referenced
this issue
Jun 23, 2024
minor: Add debug info to invalid offset error cc rust-lang/rust-analyzer#17289
|
Has the issue been resolved yet？ |
|
I still believe this is a client issue, not rust-analyzer |
|
For me, it happens very rarely, and only in some projects, but when it happens - it spams a lot (Not on every keystroke, just lots of error messages appearing at the same time, probably caused by some other plugin). I have just catched that, during appending text in the middle of existing line, no line was removed, no line was added, it failed on line 365 (the line after final newline), and R-A thinks this offset is invalid. I'm not sure how to debug it (I don't know how to reproduce it), but maybe there is no final line in RA document representation after some changes, or it was never here, but this error is caused only when RA/client queries some information on final line offset? Or just some off-by-one error in neovim LSP client/RA itself. |
|
Okay that confirms my suspicion that one side of this here is wrong about the last line. Are these happening when you edit the file? Or just browsing? ~~If the latter this is certainly a client bug as line 365 does not exist in that document. ~~ Ah wait, your editor is just not rendering a line number for the last empty line. Then this seems weird ... Can you attach some logs (specifically backtraces of the panics) the next time you run into those? |
|
Huh, I think I discovered something even funnier on neovim(?) side, now I'm wondering what information I can deduce from that behavior. Screencast_20240707_003057.mp4I have two windows open side by side, in one I have buffer of 898 lines, in other I have 756 lines. I don't think it is the same error I have found earlier, but today I have seen invalid offset multiple times on the same project (I haven't seen any problems with it earlier, but today I have merged couple of pretty big repositories without changing any versions, and here I am.), and I wonder if they might have the same cause. I don't see any panics in R-A logs, but I think this is something on neovims side, because in LSP every change has document id, and races like that should not happen. I have no idea what happened, but right now rust-analyzer lsp is completely broken and looks like its pulling information from other buffers, but applying them to current (Tried to use code actions). What's strange, is that errors are displayed in the correct buffer I believe I hit neovim/neovim#28575, will try on newer neovim. |
|
Right there shouldn't be any backtraces, this is not a panic but a general error being bubbled up back to the client.
It has to be, otherwise we'd observe this in other clients as well. Might be good to see if an older neovim doesn't have this problem |
|
I've found that reproduce this problem is when we take an rs file with content, delete it all, and save it. I can repeat the error |
|
I have the same error with latest stable neovim, mason, and rust-analyzer. Is there any work around / fix to this issue? |
Veykril
removed
the
Broken Window
|
Possibly related to neovim/neovim#19237 |
@chaozwn, I have tried neovim 0.11, but it still exists. |
|
I had that exact same error on a non empty file and it was due to cachePriming config being turned off, I enabled it back on and the error isn't showing anymore |
|
Try it: neovim/neovim#19237 and let me know if this workaround works for you. |
I just wanted to point out, for people using neovim + mason (under Linux), that the rust-analyzer installed by mason is a different one than the one installed by rustup (which is typically the one accessed through the terminal). You can find the version installed by mason by opening ":Mason" inside neovim: If you type
If instead you run rust-analyzer from the terminal (outside of neovim), you get the version installed by rustup, which is typically older. For example, for me, If you're using rust-analyzer only from within neovim + mason, and don't have a reason to run rust-analyzer independently outside of that setting, I'd recommend not installing (or uninstalling) the rustup version so there's no confusion. (And if you do need to run it outside neovim, I'd suggest using a symlink from the mason-installed version instead of installing a conflicting version from rustup. Having two different versions of rust-analyzer installed on one system can lead to subtle problems.) |
|
I got the same issue, but seems to only trigger when i quickly delete a tab and a newline. |
|
It's actually a bug in Neovim version 10 and above. I'm not sure why it happened, though. I switched back to Neovim version 9.5, and there's no issue. I suggest using bob to easily manage the version of neovim so you can test it later on when it's fixed. |
Potential FixMason downloads Check Mason's
|
I just wanted to point out that, annoyingly, the version numbering system used by rust-analyzer differs between mason and rustup and aren't directly comparable like that. For example, as you can see from my comment above, mason's v0.3.2037 is dated 2024-07-15, while rustup's 1.79.0 is dated 2024-06-10, so 0.3 is actually newer than 1.79. I've already tried symlinking to 1.79 (similar to your suggestion), and it produced the same error but with a differently worded error message. If someone has time (which I don't at the moment), it should be possible to use bisection to figure out when the error was introduced. But on my system, at least, it's the newest version of rustup which has this error. (The error reproduces at the head of the rust-analyzer repo.) |
|
This only makes this error more confusing. It should be noted that I only had this error occur after migrating my system from Fedora to Arch, and it worked perfectly fine on Fedora. This makes me think it could be an issue related to system library implementations within either nvim, Mason, or rust-analyzer which produce unintentional errors on some systems. The sheer inconsistency with which solutions work for users here may indicate multiple points of failure, as while patching This is why I'm thinking it must be a low-level dependency issue which is heavily dependent on system configuration and shared between them all, explaining the inconsistency. This is purely conjecture, but it's the first place I'd check and unit test. I tried forcing a different UTF character length in my lspconfig as recommended by some users, but then rust-analyzer gave no output at all. |
|
It seems that both neovim and rust-analyzer have some issues. environment
reproduction step: open main.rs, wait until indexing and etc finishes, then Then you will get something like this in nvim's lsp log file messagesThis issue can be fixed with the following patch to nvim. diff --git a/runtime/lua/vim/lsp/util.lua b/runtime/lua/vim/lsp/util.lua
index 59ae3beae..0615c5da1 100644
--- a/runtime/lua/vim/lsp/util.lua
+++ b/runtime/lua/vim/lsp/util.lua
@@ -2145,7 +2145,7 @@ local function make_line_range_params(bufnr, start_line, end_line, offset_encodi
---@type lsp.Position
local end_pos
- if end_line == last_line and not vim.api.nvim_get_option_value('endofline', { buf = bufnr }) then
+ if end_line == last_line then
end_pos = {
line = end_line,
character = M.character_offset(bufnr, end_line, #get_line(bufnr, end_line), offset_encoding),(Or alternatively, rust-analyzer could be modified to gracefully handle the last line eol.) update: the following is invalid. see #17289 (comment) outdatedNow repeat the same repro steps. messagesWhat happens here is that
This is odd because rust-analyzer is using some form of snapshot for global state, which would prevent such issues.
|
|
@tomtomjhj so it's either a race condition in the global state, causing request order to get messed up, or a copy/clone error. This checks out, as my prior fix I gave earlier only works until reboot, and even then is inconsistent, making me think my method isn't effective and the erroneous code is still in HEAD. I'll patch my version when I get home and report back if it fixes the bug on my end as well. Thank you so much for such thorough investigation! |
|
Updates to my comment above: Please ignore the stuff below this line
This is not an actual bug, and is just caused by the artificial panic I added in the above patch for rust-analyzer. Might be related: neovim/neovim#27383. I'll send PR to nvim after some more testing. |
|
Found a more fundamental issue in nvim where it desyncs with the server when the buffer becomes empty. Please try the fix: neovim/neovim#29904. But this doesn't eliminate all |
|
Hello, @tomtomjhj thanks for your work. I tried your fix :) NVIM v0.11.0-dev-522+g619d005ac
Build type: RelWithDebInfo
LuaJIT 2.1.1720049189
Run "nvim -V1 -v" for more info
fn main() {
println!("hello world");
}
Note it happens only the first time I open the file. If I restore the code, save it again, delete, save => I don't have the problem anymore |
|
#17742 fixed the remaining issue. For other requests, rust-analyzer has been correctly reporting errors due to invalid offset as "content modified" error, which is ignored by the client UI. However, inlay hint handler in the versions prior to #17742 reported it as an internal error (which is shown to the user) because inlay hint request was marked as retry-able. #17742 fixes this by marking it as not retry-able. |
|
I am still have this error even though I have the most recent version of rust-analyzer installed via rustup and NVIM is picking it up.
I do NOT have rust-analyzer installed via Mason: However, when saving a file I still get these errors (disregard the circles I drew, they're not related to this issue)
|
This comment has been minimized.
This comment has been minimized.
|
I found a temporary solution to it: I am using routes = {
{
filter = {
event = "notify",
error = true,
find = "Invalid offset LineCol",
},
opts = { skip = true },
},
}notify can use override |
|
I experienced the same issue with neovim. They have a fix for it in nightly. |
|
I have the same issue, would be nice to have a fix for this pushed |
|
I also do experience this issue, using Rust edition 2024 and nightly rust-analyzer seem to occur more frequently for me. |
|
It's still not fixed. |
|
Can confirm I get this error on both vscode and neovim, I have tried installing rust-analyzer both from mason and rustup but it does not solve the issue. |
|
I'm still having this issue on v0.10.3: |
|
This issue still persists in v0.10.4: |
|
This issue could also be reproduced by deleting the whole file, using |
|
The issue has been fixed for me in the nightly neovim release. |
|
I mainly have this problem not on empty files, but just normal Rust source files. The issue still isn't fixed for me. Edit: actually, this might have been because I was using an older version of |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
rust-analyzer version: 2024-05-09
rustc version: (eg. output of
rustc -V): 1.78.0editor or extension: neovim with Mason+Lspconfig+RustAnalyzer
relevant settings: none
repository link (if public, optional): none
code snippet to reproduce:
Rust analyzer is printing this error if I start editing an empty .rs file before it has completed its startup. There are no settings involved, just an empty cargo project with a main.rs. Once that error pops up, it will keep appearing on every keystroke until I close the buffer, reopen it, wait for it to fully initialize and then start writing. This does not happen if the file is not empty.
The text was updated successfully, but these errors were encountered: