rustflags in .cargo/config cause rebuilds when running "cargo build"

[dotdash]

I have a .cargo/config file to make cargo use lld on x86_64 Linux.

target.x86_64-unknown-linux-gnu]
rustflags = [ "-C", "link-arg=-fuse-ld=lld" ]

This causes cargo build when run manually to behave differently from when run from rust-analyzer, thus all crates are rebuilt. This is rather annoying when I perform test runs of my binary using cargo run as it needs to rebuilt everything, and then rust-analyzer rebuilds everything again once I return to vim.

[kdar]

I've noticed the same thing on linux when using

[target.x86_64-unknown-linux-gnu]
rustflags=["-Clinker=clang", "-Clink-arg=-fuse-ld=lld"]

Every change in my source will cause rust-analyzer to re-check all my dependencies, and cause builds to re-build all dependencies.

[alexxbb]

I have the same issue with RUSTFLAGS variable

[nhynes]

I'm also experiencing this issue. #3544 or inlining rustflags would work, I think.

[Veykril]

I am honestly a bit surprised how this can even happen as we merely invoke cargo ourselves from what I know. In which case this should also use the flags from .cargo/config just fine.

RUSTFLAGS giving problems I can see if RA isn't run with that env var since the cargo process we spawn wont have them set either then.

[emi2k01]

I had the same problem but it was because I had a wasm library in my workspace. Now I can't reproduce this issue.

[alexxbb]

After some investigation I found that constant rebuilds in my case were caused by the NFS, i.e. cargo artifacts were created on the network drive, which cased cargo to think they were out of date. Once I set CARGO_TARGET_DIR to point to my local drive, the issue disappeared.

[Veykril]

I just went and checked and this shouldn't happen anymore as long as the user sets the exact same flags in rust-analyzer.server.extraEnv, cc #4616

[Be-ing]

I encounter this issue as well as #4616 whenever I cross compile, save an edit in Kate, then go to cross compile again. This happens both with GNU ld and mold as linkers. With GNU ld, in ~/.cargo/config.toml I have:

[target.aarch64-unknown-linux-gnu]
linker = "aarch64-linux-gnu-gcc"

For mold:

[target.aarch64-unknown-linux-gnu]
linker = "clang"
rustflags = [
    "-C", "link-arg=-fuse-ld=/usr/bin/mold",
    "-C", "link-arg=--target=aarch64-redhat-linux-gnu",
    "-C", "link-arg=--sysroot=/usr/aarch64-linux-gnu/sys-root"
]

My host is x86_64-unknown-linux-gnu.

as long as the user sets the exact same flags in rust-analyzer.server.extraEnv

That is not a practical solution when developing for multiple targets each with their own compiler flags.

[uklotzde]

Unfortunately, we are also experiencing this issue.

Duplicating and maintaining common rustflags/rustdocflags using crate-level attributes in a workspace with many crates is impractical. Advising developers to synchronize their rust-analyzer settings manually is neither.

[Veykril]

r-a isn't able to do much here. This is inherent to how cargo works. The best option here is to set CARGO_TARGET_DIR to a different target dir for the rust-analyzer server. That should prevent frequent rebuilds between r-a's cargo invocations and others.

[mpfaff]

r-a isn't able to do much here. This is inherent to how cargo works.

What about this is inherent to how Cargo works? Cargo respects ~/.cargo/config.toml but rust-analyzer does not.

Edit: Setting rust-analyzer.server.extraEnv as mentioned above does not solve the problem.

Edit 2: For more context, this appears to only be an issue when compiling for wasm32-unknown-unknown, which has its own target sub-directory, and so should be isolated, no?

[Veykril]

Cargo respects ~/.cargo/config.toml but rust-analyzer does not.

It should, every cargo command r-a invokes respects the config.toml, even querying metadata should now.

Do you have a small repro by any chance?

[mpfaff]

Cargo respects ~/.cargo/config.toml but rust-analyzer does not.

It should, every cargo command r-a invokes respects the config.toml, even querying metadata should now.

Do you have a small repro by any chance?

I don't have a small one ATM, but I'll try to make one.

[willhodges]

Also being impacted by this issue. Very frustrating to try to work around. Even setting a different target directory for rust-analyzer with checkOnSave.extraArgs doesn't help; rust-analyzer continues to trigger full rebuilds. Also using wasm32-unknown-unknown as part of the workspace.

[Veykril]

How are you setting the target when compiling for wasm? If you do it manually then you'll have to set the target for r-a accordingly via rust-analyzer.cargo.target.

[willhodges]

@Veykril The cargo workspace I'm using has multiple crates with different build targets, so setting that value at the project level won't work. This seems to be an ongoing weakness with Rust tooling for wasm projects. The community clearly wants support of multi-target workspaces to build both wasm code in addition to server or tooling code with different build targets. Cargo sort of supports this right now with rust-lang/cargo#9406 (only in nightly), but overall the cargo maintainers don't seem to view this as a priority.

Would rust-analyzer respect per_package_target if I set that option in each crate's Cargo.toml and used the nightly toolchain?

If it won't, I think the workaround here is to just get rust-analyzer to respect the target dir override, but this isn't currently working for me. I'm still seeing the normal target dir being used even with the following config:
{ "server": { "extraEnv": {"CARGO_TARGET_DIR": "target/check"} } }
Thanks for your help and responses.

[Veykril]

r-a won't respect the per_package_target no

Regarding the target dir env var, thats odd, all cargo processes spawned by r-a should inherit those env vars

[willhodges]

@Veykril Thanks for the response. I've made a quick sample repository to show the issue (https://github.com/willhodges/rabug); if you pull this repository down and open the top-level folder in VSCode (with rust-analyzer extension) or Atom (with ide-rust extension, which uses rust-analyzer under the hood) they will both kick off rust-analyzer, which creates the target directory, and then target/check and target/debug, which I believe suggests that r-a is ignoring the CARGO_TARGET_DIR in rust-analyzer.json. It's hard to guarantee that that is true without being able to run r-a directly instead of relying on the editor to do it indirectly. I'd be happy to learn that I'm wrong here.

[Veykril]

can you create a new issue for that? Otherwise this will be overlooked as this issue is about rustflags specifically

[willhodges]

@Veykril I'm seeing this issue now even without using rust-analyzer, so it appears to be an issue with Cargo itself, likely this one: rust-lang/cargo#10839