New versions of rust-analyzer seem to fail on certain crates like `web-sys`

[grovesNL]

rust-analyzer version: rust-analyzer version: 0.3.2104-standalone (08c7bbc2d 2024-09-06)

rustc version: (eg. output of rustc -V): rustc 1.81.0 (eeb90cda1 2024-09-04

editor or extension: (eg. VSCode, Vim, Emacs, etc. For VSCode users, specify your extension version; for users of other editors, provide the distribution if applicable): VSCode, rust-analyzer extension v0.3.2104

relevant settings: (eg. client settings, or environment variables like CARGO, RUSTC, RUSTUP_HOME or CARGO_HOME): doesn't seem to be relevant as far as I can tell

repository link (if public, optional): (eg. rust-analyzer): private

code snippet to reproduce: follow the steps below

cargo new --lib rust-analyzer-problem
cd rust-analyzer-problem
cargo add web-sys
# don't build at this point

Open VSCode to that new crate and rust-analyzer might fail with something like this:

2024-09-10T14:14:42.057617Z ERROR FetchBuildDataError: error: extern location for js_sys does not exist: <snip>\rust-analyzer-problem-1\target\debug\deps\libjs_sys-4f976da99a8dfffa.rmeta
  --> <snip>\.cargo\registry\src\index.crates.io-6f17d22bba15001f\web-sys-0.3.70\src/lib.rs:20:9
   |
20 | pub use js_sys;
   |         ^^^^^^
error: extern location for wasm_bindgen does not exist: <snip>\rust-analyzer-problem-1\target\debug\deps\libwasm_bindgen-e83206b04672971c.rmeta
  --> <snip>\.cargo\registry\src\index.crates.io-6f17d22bba15001f\web-sys-0.3.70\src/lib.rs:21:9
   |
21 | pub use wasm_bindgen;
   |         ^^^^^^^^^^^^
error: aborting due to 2 previous errors
error: could not compile `web-sys` (lib) due to 3 previous errors

If you then try to run cargo build manually and restart rust-analyzer's server then it seems to start working again. That workaround isn't too bad for regular use because a lot of people will build often anyway.

In a larger project though, I like to use "rust-analyzer.cargo.targetDir": true to run rust-analyzer and tests with different configurations without blocking each other. However because of cargo build needing to run for rust-analyzer to work, the targetDir option can't work anymore, because rust-analyzer reports errors like:

error[E0277]: the size for values of type `gen_Window::Window` cannot be known at compilation time
   --> D:\projects\.cargo\registry\src\index.crates.io-6f17d22bba15001f\web-sys-0.3.70\src\features\gen_Window.rs:157:37
    |
157 |     pub fn frames(this: &Window) -> Result<Window, JsValue>;
    |                                     ^^^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
    |
    = help: the trait `Sized` is not implemented for `gen_Window::Window`
note: required by an implicit `Sized` bound in `Result`
   --> D:\projects\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib/rustlib/src/rust\library\core\src\result.rs:527:17
    |
527 | pub enum Result<T, E> {
    |                 ^ required by the implicit `Sized` requirement on this type parameter in `Result`
error: aborting due to 2908 previous errors

(I can't easily get to the start of this log, but I assume this is caused by the same failure as the case above)

[Veykril]

Try setting rust-analyzer.cargo.buildScripts.useRustcWrapper to false and see if that fixes it. I imagine the crate's build scripts might be trying to do probing that the wrapper interferes with

[grovesNL]

"rust-analyzer.cargo.buildScripts.useRustcWrapper": false does seem to work, thanks! Is there anything we could do to handle this better? e.g., fixing the probing upstream if there's a recommended approach