Add rust-toolchain file

[IceSentry]

Objective

• When bisecting a bug we end up using older versions of bevy that don't always compile with the most recent compiler
• We use cutting edge features and not everyone has the latest compiler version installed and they end up seeing errors that might not be easy to understand

Solution

• Add a rust-toolchain file to document which compiler version is used for the current state of the repo
• This way when using git bisect we don't have to guess at which compiler version we should be using
• This means we will have to make a new PR to update the file every time there's a new rust version or at least every time we use a feature from a newer rust version
• Unfortunately, this caused a few issues with CI so I had to add rustup override steps to a few of the CI actions that were expecting a specific rust version or component. This way CI essentially doesn't have to care about the toolchain file.

Testing

• I tested a local build and it used the expected compiler version

[github-actions]

You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.

[mockersf]

could you set up dependabot to update it? https://github.blog/changelog/2025-08-19-dependabot-now-supports-rust-toolchain-updates/

[IceSentry]

I added a daily dependabot job for the rust-toolchain. Not sure if that's the best schedule. I wouldn't be surprised if a human will always end up doing it first since a rust release is hard to miss for anyone that tracks them

[cart]

I see the value in being exact, but before adding semi-redundant "things", can you verify that the minimum Rust version in Cargo.toml does not meet your needs?

[package]
rust-version = "1.88.0"

[IceSentry]

Ah, I didn't realize we even had a rust version specified.

Are you saying I should set the toolchain value to match that 1.88 or are you saying that the toolchain file is redundant?

[cart]

I'm saying it is partially redundant. It is a piece of metadata that we already bump periodically, that is an attestation that Bevy requires features from that version.

The big tradeoff is that we aren't actually running our CI for that version (we use latest stable).

[cart]

The question is ... is that enough of a solve for your usecase, given that the proposal adds more complexity to our process.

[IceSentry]

I admit that being aware of the rust version does change things a little bit, but in my case the reason I want it is for the ability to git bisect and having cargo automatically detect the toolchain it should be using makes it simpler. With that said, yeah, I guess the rust-version field solves the "guessing the compatible rust version" part. Either it didn't exist until recently or that field is essentially ignored by cargo though, because me and many people I've talked to on discord have had issues with invalid rust versions when running git bisect.

[mockersf]

The big tradeoff is that we aren't actually running our CI for that version (we use latest stable).

We don't run all the CI on it, but Bevy is built in CI with the rust version from rust-version in this job: https://github.com/bevyengine/bevy/blob/main/.github/workflows/ci.yml#L456

it didn't exist until recently

It was (only) added 3 years ago

I think the issue is maybe with lints (builtin or clippy), with every rust version having new lints that Bevy fails. Or it did happen a few times that new versions of Rust don't compile Bevy, this is fixed usually well enough in advance by the Rust team with PR to Bevy, but if you go back in history with a modern version of rust it will fail to compile.