Rebuild thrashing when using Rust Analyzer in VSCode with fast build config

[hintron]

My problem is that VSCode's Rust Analyzer extension seems to get confused when fingerprinting, marking things as dirty and forcing some crates to rebuild. Perhaps Rust Analyzer isn't respecting the rust flags, or perhaps the envs are different. So Rust Analyzer rebuilds, then I call cargo check or cargo build in the terminal to rebuild, and this repeats, back and forth...

Has anyone else run into this issue? I've only just noticed this on Windows + Git Bash after wondering why my rebuilds were so slow.

My Cargo.toml contains:

[profile.dev.package."*"]
opt-level = 3

[dependencies]
bevy = { version = "0.14", features = ["dynamic_linking"] }

and my .cargo/config.toml comprises of

[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = [
  "-Clink-arg=-fuse-ld=lld",
  "-Zshare-generics=y",
  "-Zthreads=0",
]

[target.x86_64-apple-darwin]
rustflags = [
  "-Zshare-generics=y",
  "-Zthreads=0",
]

[target.aarch64-apple-darwin]
rustflags = [
  "-Zshare-generics=y",
  "-Zthreads=0",
]

[target.x86_64-pc-windows-msvc]
linker = "rust-lld.exe"
rustdocflags = ["-Clinker=rust-lld.exe"]
rustflags = [
  "-Zshare-generics=n", # This needs to be off if you use dynamic linking on Windows
  "-Zthreads=0",
]

The workaround is probably just to make sure the VSCode Rust Analyzer has its own target directory, but that seems brittle since it's per-IDE and isn't versioned to my repo. I tried "rust-analyzer.cargo.targetDir": true, but it still thrashes for me.

While I don't think this is Bevy's fault, I do think that this "foot gun" and possible workaround should be warned about in the fast build config docs, since Rust Analyzer hasn't addressed the issue. Also, I'm curious if others can reproduce this.

[hintron]

The workaround is probably just to make sure the VSCode Rust Analyzer has its own target directory, but that seems brittle since it's per-IDE and isn't versioned to my repo. I tried "rust-analyzer.cargo.targetDir": true, but it still thrashes for me.

Actually, I was able to get this workaround working, but only after commenting out the cargo check call in my Git pre-commit hook, as that was yet a third source of the thrashing.

[Earthmark]

I believe this is an alternative report of BLAKE3-team/BLAKE3#324

[hintron]

Ah, interesting. I did notice that blake3 was the first package that was being recompiled, so I believe it

[janhohenheim]

I was about to close this issue, but since this has come up time and again, I think it would be good if we documented it somewhere.

[hintron]

@janhohenheim Has this come up in any other Bevy issues to date? I'm trying to get more info

[janhohenheim]

@hintron not sure about GitHub issues, but this has definitely come up on Discord a lot.
I think this is only an issue on Windows, but I'm not sure. Let me know if I should remove the O-Windows label.

[DGriffin91]

Not directly bevy related, but this totally wrecks hot reloading in https://github.com/DGriffin91/ridiculous_bevy_hot_reloading

[hintron]

I believe I was able to fix the issue upstream in BLAKE3 with this PR: BLAKE3-team/BLAKE3#413.

For anyone else having this issue, can you try my bug fix to see if it works? Simply add this to your Cargo.toml and let me know if it works for you!:

[patch.crates-io]
# For testing fix for blake3 env change rebuild thrashing issue
blake3 = { git = "https://github.com/hintron/BLAKE3", branch = "hintron/fix-blake-rebuild-issue"}

[janhohenheim]

Ping @MiniaczQ, you just had this issue

[DGriffin91]

@hintron Works for me, thanks!

[hintron]

I confirmed that the issue does not happen on Linux. It seems to be a Windows-only issue.

[janhohenheim]

Since blake3 just release version 1.5.2 which includes your changes, I'll close it as complete.
@hintron thank you so much for fixing this! I have also run into this in the past and I'm glad that new users won't be bothered by sporadic rebuilds anymore :)

[hintron]

It was fun to debug! Glad to be of help.

For anyone else with this issue on Windows with Bevy 0.13 or 0.14, just do cargo update blake3 or cargo update to pull in the fix.