Do not trust the `.crates.toml`

[Veetaha]

Hi. I am seeing the error on CI that iai-callgrind-runner command is not available,

even though cargo-binstall said that the binary is already installed in the CI step above.

I think the problem is that I somehow fucked up the caching on CI. The setup-rust-toolchain action caches cargo home, including the .crates.toml and the bin directory, but for some reason there is no iai-callgrind-runner binary in the bin directory.

This worked fine on the first CI run on master because cargo-binstall didn't skip downloading the binary.

I can add --force flag as a workaround, but I think, in general, cargo binstall should not trust .crates.toml and do a double integrity check that the binary is actually available in the bin directory, and that it has an executable bit set at least. If not - suggest downloading the binary as usual with maybe a warning saying that .crates.toml <-> bin integrity issue was detected. Or it could be a hard error to avoid footguns

---

UPD:

I think I found why my cache was fucked up. Seems like setup-rust-toolchain action cleans the bins directory:
https://github.com/elastio/bon/actions/runs/15915391654/job/44891997214#step:13:45

This is the related issue in Swatinem/rust-cache: Swatinem/rust-cache#204

[NobodyXu]

Yeah I think it's a caching issue, cleaning the bins while keeping the binaries is kind of terrible.

You can try taiki-e/install-actions in the meantime, I think it already uses -f, easy to use and have pretty good support for common software, not just rust ones

[Veetaha]

You can try taiki-e/install-actions

Well, I'm using that action to install cargo-binstall, and after that I use cargo-binstall to install iai-callgrind-runner. I don't see iai-callgrind-runner tool mentioned in install-action's tools support doc, that's why I'm using cargo-binstall as an intermediate installer, and this is what's recommended in iai-callgrind docs actually.

Anyway, I have resolved this problem by adding a --force flag. I just created this issue as a suggestion to improve the error handling. Today cargo-binstall blindly trusts .crates.toml, but I think it should additionally check that the binary exists at the expected path and that it's executable (i.e. has executable permission set on Linux - this info is available via std::fs::metadata())

[NobodyXu]

Yeah that makes a lot of sense, I would spend some times this weekend adding it.