Spurious failure to load a `.rs` file from `OUT_DIR`

[ghost]

FWIW I'm seeing this in a multi-crate repository (tagged to a commit that exhibits the issue). It appears that RA may be trying to use the wrong path relative to the crate to load the included file? The project(s) build fine with cargo, so the error is simply wrong.

The path in the error message is (relative to repository root): libretro-rs/target/debug/build/libretro-rs-sys-37adac34f8f4cbf3/out/libretro.rs

But the path I would expect is: libretro-rs-sys/target/debug/build/libretro-rs-sys-86130f2702103941/out/libretro.rs

However, the path in the error message does exist, since the libretro-rs crate depends on the libretro-rs-sys crate in the same repository. It appears that RA is getting confused and I don't think the solution should involve adding configuration to straighten it out. If cargo can figure it out then RA should be able to as well.

$ cargo build
   Compiling libretro-rs-sys v0.1.0 (/home/adam/Repos/libretro-rs/libretro-rs-sys)
   Compiling libretro-rs v0.1.3 (/home/adam/Repos/libretro-rs/libretro-rs)
   Compiling example v0.1.0 (/home/adam/Repos/libretro-rs/example)
    Finished dev [unoptimized + debuginfo] target(s) in 0.93s

If this issue is unrelated, I'll make a new issue.

Originally posted by @adam-becker in https://github.com/rust-lang/rust-analyzer/issues/10178#issuecomment-1107666673

[bjorn3]

It looks like you aren't using a cargo workspace so it will load libretro-rs and libretro-rs-sys independently with separate target dirs and configuration. Maybe the configuration for the libretro-rs-sys crate from the libretro-rs root and from the libretro-rs-sys root conflict or something like that? Try adding a Cargo.toml with the following contents:

[workspace]
include = ["libretro-rs", "libretro-rs-sys"]

It is very much possible that this is not the issue though.

[ghost]

@bjorn3 I'll give that a try and see if it works around the issue.

I do want to be clear that even if the suggestion does work around the issue, it is still a work around. At the end of the day, cargo has no issues figuring out what to do here, and RA gives me an error. That divergence in behavior is the issue here.

[flodiebold]

The problem doesn't reproduce for me. I'm not sure the choice of target folder is actually the problem, considering the file does exist :thinking: I assume restarting VSCode does not change anything?

[ghost]

The problem doesn't reproduce for me. I'm not sure the choice of target folder is actually the problem, considering the file does exist thinking I assume restarting VSCode does not change anything?

I've restarted VS code and also ran cargo clean and let RA run cargo check to regenerate the folder. Same issue.

The interesting thing is that it worked at one point. I've been trying to figure out what change caused this to happen for me.

[swimricky]

i've also hit this issue where it seems inconsistent I'm using tonic::include_proto!("my_proto") and get the same "failed to load file" error but I can clearly see the file it fails to load in my workspace. Sometimes it goes away and I have no idea why and as soon as I think it's no longer an issue it comes back

[pdeva]

facing same issue. tried in both vscode and zed and issue repros every time for me

[kkafar]

I can confirm this / #18748 still happens. I can reproduce this on a project I've just started working on: https://github.com/kkafar/dsync/tree/3d2e91319ee11366104f3d1b090bb233366769ba

To reproduce:

1. Clone the repo ☝
2. open it in zed / vscode
3. go to command_impl.rs file & try to go definition of LisHostsRequest symbol