RA shows warnings in autogenerated files inside target directory when using alternative target location

[martin-t]

rust-analyzer version: 0.0.0 (cc0bb71 2022-07-02)

rustc version: rustc 1.64.0-nightly (46b8c23f3 2022-07-01)

relevant settings:

{
    "rust-analyzer.server.extraEnv": {
        "CARGO_TARGET_DIR": "target-ra"
    },
    "rust-analyzer.checkOnSave.command": "clippy"
}

I use target-ra as a separate target directory for RA in VSCode. My project uses lalrpop which puts generated files in this target directory. RA shows warnings in one of these autogenerated files (target-ra/debug/build/fml-738faf2a1534b33c/out/fml.rs). I think this is a bug because it doesn't show warnings if using the normal shared target directory and in general it makes no sense to show warns in files i can't do anything about.

It can be reproduced on this repo on the ra-bug branch. It contains a .vscode config that should contain everything needed - the warnings should be visible as soon as RA finishes analyzing the project:

Interestingly, there are other target-ra/debug/build/fml-*/out/fml.rs files but it only happens with this particular one.

[flodiebold]

Does running cargo clippy in the terminal show any warnings?

In general I would expect warnings to show up in generated files as usual. If you don't want to see them, you can #[allow] them, but they might actually be warning you about something you can change by changing the code that generates them.

The reason why you only see the warnings for one file is that this is the current generated file; the other ones are older versions that are not part of the crate anymore. And I suspect the reason why you're only seeing them now with a separate target folder is that /target is ignored by default, and your new target folder isn't. (Probably through .gitignore, though maybe VSCode also has some other setting.)

[flodiebold]

(Lastly, I wouldn't usually recommend using a different target folder for RA. Unless you have something in your setup that results in different build parameters being used when RA runs cargo check vs. when you run it in the terminal, separating target folders will just cost you time and disk space.)

[martin-t]

Does running cargo clippy in the terminal show any warnings?

Hmm, it does. I was convinced it wouldn't because VSCode doesn't show anything in the default target and didn't bother checking.

In general I would expect warnings to show up in generated files as usual. If you don't want to see them, you can #[allow] them, but they might actually be warning you about something you can change by changing the code that generates them.

Yeah, this makes sense.

The reason why you only see the warnings for one file is that this is the current generated file; the other ones are older versions that are not part of the crate anymore. And I suspect the reason why you're only seeing them now with a separate target folder is that /target is ignored by default, and your new target folder isn't. (Probably through .gitignore, though maybe VSCode also has some other setting.)

Both target and target-ra are in gitignore. So now that i think about it, the bug is that warnings are not shown for the default target. I would definitely expect them to behave the same.

(Lastly, I wouldn't usually recommend using a different target folder for RA. Unless you have something in your setup that results in different build parameters being used when RA runs cargo check vs. when you run it in the terminal, separating target folders will just cost you time and disk space.)

I have VSCode set to save when it loses focus which triggers RA which locks target and blocks the build i start from my terminal. By using a separate target dir, i can avoid this delay.

[lnicola]

and blocks the build i start from my terminal

It doesn't block the build, it starts it opportunistically, so it's often finished by the time you type cargo check. It doesn't slow down anything.

[flodiebold]

It might seem like you're blocked since you're seeing the "waiting for lock" message, but in practice you're just waiting for the time cargo check takes and then immediately seeing the results, so you're not actually waiting any longer (and potentially shorter because the build started faster). On the other hand with a separate build directory you're running two builds in parallel, so they will actually be slower.

I'm not sure why warnings aren't shown for target. This might be a VSCode thing? It would be interesting to see in the server trace whether we actually send the diagnostics or not.

[lnicola]

I think there's a recent regression where the cargo check diagnostics only show up when saving a file, but not on project load (or they show up, then disappear).

[flodiebold]

I don't think that's it, since diagnostics in other files show up.

[martin-t]

It doesn't block the build, it starts it opportunistically, so it's often finished by the time you type cargo check. It doesn't slow down anything.

This is absolutely not my experience. I have set RA to run clippy on save, I configured VSC autosafe delay to 100 ms (so it can often actually save and start analyzing before it loses focus, i forgot i made this change) but when I switch to my terminal, cargo build blocks for several seconds due to RA.

It might seem like you're blocked since you're seeing the "waiting for lock" message, but in practice you're just waiting for the time cargo check takes and then immediately seeing the results, so you're not actually waiting any longer (and potentially shorter because the build started faster).

I almost never do cargo check in terminal, i wanna build and run the code (or sometimes tests). I am not sure cargo build is able to reuse analysis done by cargo check, it doesn't seem like it in my testing so there's no benefit to running check in RA and then build in terminal if build has to wait for check to finish.

Also note that i want clippy lints in VSC and clippy takes way longer than build and still blocks the target dir.

On the other hand with a separate build directory you're running two builds in parallel, so they will actually be slower.

That's a good point i haven't considered yet. OTOH i only care about incremental build times so only the topmost crate in the dep tree is being checked/built. I believe rustc isn't very parallelized and so cargo build is only using one core (confirmed by eyeballing CPU usage graph) but clippy does seem to use multiple cores so it could slow the build down. I wonder if i could hack around this issue by playing with niceness.

This discussion is probably a bit off-topic for this issue, though i don't mind continuing it here. OTOH this is something that probably deserves a lot deeper investigation because build times are by far the worst part of using rust for me, using a separate target for RA has improved it massively and yet i have not seen it suggested anywhere else (and in fact most articles about build times are about from-scratch, not incremental, which is strange).

---

Back to the issue:

I'm not sure why warnings aren't shown for target. This might be a VSCode thing? It would be interesting to see in the server trace whether we actually send the diagnostics or not.

I looked at Output -> Rust Analyzer Language Server (when using the normal shared target) and saw this line repeated a lot:

[ERROR rust_analyzer::main_loop] File with cargo diagnostic not found in VFS: file not found: /home/martin/dev/rust/FML-bug/target/debug/build/fml-738faf2a1534b33c/out/fml.rs

That's the path of the file that should show the warns but doesn't.

There's also:

thread 'MacroExpander' panicked at 'assertion failed: `(left != right)`
  left: `0`,
 right: `0`', crates/proc-macro-srv/src/abis/abi_1_63/proc_macro/bridge/handle.rs:22:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/core/src/panicking.rs:142:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
   4: proc_macro_srv::abis::abi_1_63::proc_macro::bridge::client::HandleStore<S>::new
   5: proc_macro_srv::abis::abi_1_63::proc_macro::bridge::server::run_server
   6: proc_macro_srv::abis::abi_1_63::proc_macro::bridge::server::<impl proc_macro_srv::abis::abi_1_63::proc_macro::bridge::client::Client<(proc_macro_srv::abis::abi_1_63::proc_macro::TokenStream,proc_macro_srv::abis::abi_1_63::proc_macro::TokenStream),proc_macro_srv::abis::abi_1_63::proc_macro::TokenStream>>::run
   7: proc_macro_srv::abis::abi_1_63::Abi::expand
   8: proc_macro_srv::abis::Abi::expand
   9: proc_macro_srv::dylib::Expander::expand
  10: proc_macro_srv::cli::run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[Veykril]

That stack trace comes from you using a nightly thats too new for r-a right now, the proc-macro abi changed again which causes us to fail expanding them. #12600