Unknown file error on textDocument/hover

[0x7CFE]

tldr: When I load my project Rust Analyzer starts flooding the console with messages like these:

[Error - 5:18:10 PM] Request textDocument/hover failed.
  Message: unknown file: /home/korvin/work/Parity/substrate-node-template/runtime/src/utxo.rs
stack backtrace:
   0: failure::backtrace::internal::InternalBacktrace::new::hb70100bfb7a580fd (0x55a207199d5f)
             at /home/korvin/.cargo/registry/src/git.cakeli.workers.dev-1ecc6299db9ec823/failure-0.1.5/src/backtrace/internal.rs:44
   1: failure::backtrace::Backtrace::new::h97063d1c45ba6677 (0x55a207199fef)
             at /home/korvin/.cargo/registry/src/git.cakeli.workers.dev-1ecc6299db9ec823/failure-0.1.5/src/backtrace/mod.rs:111
      <failure::backtrace::Backtrace as core::default::Default>::default::hcf04c262efe60191
             at /home/korvin/.cargo/registry/src/git.cakeli.workers.dev-1ecc6299db9ec823/failure-0.1.5/src/backtrace/mod.rs:125
   2: <failure::error::error_impl::ErrorImpl as core::convert::From<F>>::from::h3ab35b9b654c5c1e (0x55a206d9ee6c)
             at /home/korvin/.cargo/registry/src/git.cakeli.workers.dev-1ecc6299db9ec823/failure-0.1.5/src/error/error_impl.rs:19
      <failure::error::Error as core::convert::From<F>>::from::h45fd111b4a40a452
             at /home/korvin/.cargo/registry/src/git.cakeli.workers.dev-1ecc6299db9ec823/failure-0.1.5/src/error/mod.rs:36
      failure::error_message::err_msg::h635b7dbde3343ea4
             at /home/korvin/.cargo/registry/src/git.cakeli.workers.dev-1ecc6299db9ec823/failure-0.1.5/src/error_message.rs:12
      ra_lsp_server::server_world::ServerWorld::uri_to_file_id::{{closure}}::h4d12467267fe29dc
             at crates/ra_lsp_server/src/server_world.rs:257
      <core::option::Option<T>>::ok_or_else::hc21565f0ef482cd5
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libcore/option.rs:528
      ra_lsp_server::server_world::ServerWorld::uri_to_file_id::h12409871fb309fcf
             at crates/ra_lsp_server/src/server_world.rs:253
   3: <&'a lsp_types::TextDocumentIdentifier as ra_lsp_server::conv::TryConvWith>::try_conv_with::h104bfeb956e96bd0 (0x55a206dc1d90)
             at crates/ra_lsp_server/src/conv.rs:234
      <&'a lsp_types::TextDocumentPositionParams as ra_lsp_server::conv::TryConvWith>::try_conv_with::h3b604a4c10581ac6
             at crates/ra_lsp_server/src/conv.rs:242
   4: ra_lsp_server::main_loop::handlers::handle_hover::hba5e817577cfba3c (0x55a206dccf28)
             at crates/ra_lsp_server/src/main_loop/handlers.rs:446
   5: ra_lsp_server::main_loop::PoolDispatcher::on::{{closure}}::hf851038b39951503 (0x55a206d3480f)
             at crates/ra_lsp_server/src/main_loop.rs:441
      <F as threadpool::FnBox>::call_box::hdcdc83bd09b08650
             at /home/korvin/.cargo/registry/src/git.cakeli.workers.dev-1ecc6299db9ec823/threadpool-1.7.1/src/lib.rs:95
   6: threadpool::spawn_in_pool::{{closure}}::ha4d43bb0342d423b (0x55a206e60832)
             at /home/korvin/.cargo/registry/src/git.cakeli.workers.dev-1ecc6299db9ec823/threadpool-1.7.1/src/lib.rs:767
      std::sys_common::backtrace::__rust_begin_short_backtrace::hffad098dc90fea63
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libstd/sys_common/backtrace.rs:136
   7: __rust_maybe_catch_panic (0x55a207261cf9)
             at src/libpanic_unwind/lib.rs:102
   8: std::panicking::try::hfc053a4d611b11c9 (0x55a206e5e13b)
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libstd/panicking.rs:289
      std::panic::catch_unwind::h379924226dec8b17
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libstd/panic.rs:398
      std::thread::Builder::spawn_unchecked::{{closure}}::h47544204483651c8
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libstd/thread/mod.rs:476
      <F as alloc::boxed::FnBox<A>>::call_box::h17f0e2f6677f0a8a
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/liballoc/boxed.rs:673
   9: <alloc::boxed::Box<(dyn alloc::boxed::FnBox<A, Output=R> + 'a)> as core::ops::function::FnOnce<A>>::call_once::hece536cf07b94f8d (0x55a2072558bd)
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/liballoc/boxed.rs:683
      std::sys_common::thread::start_thread::h9605a7df0f911844
             at src/libstd/sys_common/thread.rs:24
      std::sys::unix::thread::Thread::new::thread_start::hca8e72c41fa9d291
             at src/libstd/sys/unix/thread.rs:90
  10: start_thread (0x7fd2cd3246b9)
  11: clone (0x7fd2cce4441c)
  12: <unknown> (0x0)
  Code: -32603 

Please note, that the path /home/korvin/work/Parity/substrate-node-template/runtime/src/utxo.rs is valid and it's one of the files being edited. The same file may be found here https://github.com/paritytech/substrate-node-template/blob/utxo/runtime/src/utxo.rs.

HEAD of the analyzer repo:

$ git show
commit 97ade899937dafcafa852177c85edb22ce0b80dc
Merge: 777c79c 00e6b5d
Author: bors[bot] <bors[bot]@users.noreply.github.com>
Date:   Thu Jan 31 07:06:31 2019 +0000

[pnkfelix]

Hey @0x7CFE , what Operating System are you on?

(I am seeing something similar in my attempt to use rust-analyzer with Visual Studio Code on Mac OS X. My first instinct is that its something vfs, which matches up with @matklad 's hypothesis over here: #773 (comment) )

[0x7CFE]

Hi! I'm using Ubuntu Linux 16.04.5 and looks like this issue disappeared in recent versions of Rust Analyzer.

Just in case, my directory hierarchy contains symlinks, maybe that affected the issue somehow.

[lnicola]

Closing, presumably fixed.

[AThilenius]

Is there any way to suppress all or specific errors from the rust-analyzer vscode extension? 🙏 I have this error pop often hundreds of times a day (that's no hyperbole).

It's painfully distracting. Each time it happens vscode plays the toast animation regardless of if I've cleared it or not. I tried v0.4.1367 just to make sure this isn't fixed in a later version (published 4 hours ago).

VSCode won't provide a means of error suppression. Cant' say I agree with that; blacklisting repeat errors seems like a perfectly reasonable request, but c'est la vie. My only hope at holding onto sanity is stopping the error propagation.

[matklad]

Much better would be to actually fix the error. For that, a minimal reproducible example would be the first step.

[AThilenius]

@matklad It's possible there is something goofy with (all) of my systems, because a 'minimal repro' is pretty much any rust development, on either WSL2 or SSH to Ubuntu. If I have compiler errors and start moving the cursor around I often get these. If that's abnormal I can do some digging?

I hear you on wanting to fix the root of the error. That a valiant desire. But, counterargument... I use rust-analyzer as a guiding hand but am not a contributor to the project. In other words, I'm the 'stable branch' user who is shy of anything that gets in the way of the software I need to write. Stability in tooling is paramount for me, because I already deal with so much instability in my own code. While admirable to want to release software with no bugs, I think a 'stable branch' should insulate the end user from as much as feasible. Automated crash reporting is a better solution for gathering errors than user-pain.

I hope this doesn't come across as negative, I value the rust community and tooling immensely! This one bug has just been driving me a bit batty, like a splinter you can't get at.

[Veykril]

If it happens on all projects its tough to make a minimal repro so dw :) Can you check the logs the next time it happens (ideally it should show a stack trace). Relevant log is Rust Analyzer Language Server

[AThilenius]

Yep, easy to do, just tabbed back to the project I have open and wiggled the mouse a bit. Link to project source is in there too: https://gist.github.com/AThilenius/f7ea00c9bf61720c9ab2680e103b40e4

Env:
Host platform: Ubuntu 22.04.1 LTS
VSCode running on Windows 11 (remote development with Remote - SSH extension)
rust-analyzer extension version: v0.3.1361

[bjorn3]

That is #13951

[matklad]

Automated crash reporting is a better solution for gathering errors than

user-pain. Yeah, that’d be a better solution, but that runs into two problems: * someone has to operate crash-report collecting software. I don’t think either Rust project or VS Code have anything built-in for us to re-use? * automated collection of use data in form of crash reports is a very sensitive topic, so some amount of community-wide consensus building would be required first. I wonder if can make the error message more helpful here though? It should at least teach the user where to look for panic stack-trace…

…

On Sunday, 15 January 2023, Lukas Wirth ***@***.***> wrote: If it happens on all projects its tough to make a minimal repro so dw :) Can you check the logs the next time it happens (ideally it should show a stack trace). Relevant log is Rust Analyzer Language Server [image: image] <https://user-images.githubusercontent.com/3757771/212570164-b8ddccf4-af7e-4c8a-a077-bb8a77ea7d7e.png> — Reply to this email directly, view it on GitHub <#717 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANB3M5WGYJTYGYCPPYWEG3WSRZ33ANCNFSM4GTQAABA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[bjorn3]

Another option would be to add a "report bug" button to the error message which opens a pre-filled new issue page in your browser but not submit it so you can still remove anything you don't like to share. That would significantly reduce friction. I myself skip reporting issues 9 out of 10 times because filling out an issue takes several minutes.

[Veykril]

We can't change the error message notification unfortunately, I've looked into that into the past and it happens too early in the language client implementation of VSCode.

[AThilenius]

someone has to operate crash-report collecting software. I don’t think either Rust project or VS Code have anything built-in for us to re-use?

Looks like VSCode has some support for it: https://code.visualstudio.com/api/extension-guides/telemetry It also has guidelines on user consent and PII. Telemetry data will be more useful for this kind of stuff anyway, because you'll implicitly know if it's systemic or something with my specific setup.

If you're hoping to stick with human-triggered dumps, then I think there are many solutions you could explore. Trap the crash somehow (dump to file and check for existence on reboot, or catch_unwind if it's feasible) then show a custom notification with a report button. My feature request there would be to have a 'Suppress Similar Errors' button as well, maybe in the crash dump dialog box.

Edit: we've strayed way off topic from the original post, should I open a separate Issue for this?