Setting build flags in .cargo/config.toml breaks incremental compilation

[MasonMcGill]

I'm working on a wasm/web_sys project, and when the rust-analyzer extension is enabled in VSCode, adding the following .cargo/config.toml file to my project causes every cargo run to rebuild the project from scratch (after blocking on "waiting for file lock on build directory" for a few seconds):

[build]
rustflags = ["--cfg=web_sys_unstable_apis"] # Enables experimental web APIs

Replacing "build" with "target.wasm32-unknown-unknown" solves the build problem, but causes rust-analyzer to emit errors when the experimental parts of web_sys are used.

rust-analyzer version: 0.0.0 (75b22326d 2022-07-03) rustc version: 1.62.0 (a8314ef7d 2022-06-27)

[Veykril]

Replacing "build" with "target.wasm32-unknown-unknown" solves the build problem, but causes rust-analyzer to emit errors when the experimental parts of web_sys are used.

What errors, setting the target would be the right choice here usually, you want r-a to build with the same environment as your normal builds to prevent these rebuilds (and r-a should honor the .cargo/config.toml)

[MasonMcGill]

Hi — thanks for getting back so quickly. Putting the rustflags in the target section I'd get error squigglies under symbols gated by --cfg=web_sys_unstable_apis (like those from the WebUSB API). Doing a bit more experimentation, I figured out that this config makes both the static analysis and the build command work as expected:

[build]
target = "wasm32-unknown-unknown"

[target.wasm32-unknown-unknown]
rustflags = ["--cfg=web_sys_unstable_apis"]

so at least for this project I no longer have an issue. I did spend a lot of time trying to figure this out, though—all the blog posts/stack overflow threads I could find suggested putting the rust flags in the build section—so this may be a UX issue for other, too.

[Veykril]

Ah, were you passing the build target explicitly when invoking cargo? Then that would explain the issue since r-a won't do that unless you set the target somewhere that will affect its cargo usage (like in the .cargo/config.toml here)

[MasonMcGill]

I was building with Trunk (https://trunkrs.dev/; it's a lot like wasm-pack), so I believe so, but I wasn't invoking Cargo directly. The progression was basically

1. Using Trunk + ra to make a web_sys app ... ✅ Works great
2. Defining RUSTFLAGS to enable the WebUSB API ... ❌ rust-analyzer errors
3. Moving the rust flags from the Trunk invocation to .cargo/config.toml ... ❌ Errors are gone but now builds take 20 seconds each
4. [Solution described above] ... ✅ All good again

The ra errors in state 2 all made sense to me. The surprising thing for me was that moving from state 2 to state 3 introduced a new issue.

[Veykril]

Well, it'll depend on how trunk invokes cargo. You'll need to mirror what trunk does for r-a, otherwise r-a's cargo invocations will invalidate the build cache which is expected.

[MasonMcGill]

Right, that all makes sense. I was just providing UX feedback that, as someone fairly new to Rust, figuring out that my code editor's static analysis engine had the capacity to invalidate my build cache was very surprising/unintuitive. Now that I'm aware of that, though, this issue no longer affects me.

[ilyvion]

Is it possible to get r-a to use a different build cache for its work than ./target? I don't want each r-a invocation of clippy to invalidate my build cache each time, but I also don't want to have to set up r-a with specific --target settings because I use multiple and I want to be able to call --target <whatever> over and over again while making changes without having my builds invalidated by r-a in-between.