Upgrade to Rust Edition 2024

[bushrat011899]

Objective

• Fixes Upgrade to Rust edition 2024 #17960

Solution

• Followed the edition upgrade guide

Testing

• CI

---

Summary of Changes

Documentation Indentation

When using lists in documentation, proper indentation is now linted for. This means subsequent lines within the same list item must start at the same indentation level as the item.

/* Valid */
/// - Item 1
///   Run-on sentence.
/// - Item 2
struct Foo;

/* Invalid */
/// - Item 1
///     Run-on sentence.
/// - Item 2
struct Foo;

Implicit ! to () Conversion

! (the never return type, returned by panic!, etc.) no longer implicitly converts to (). This is particularly painful for systems with todo! or panic! statements, as they will no longer be functions returning () (or Result<()>), making them invalid systems for functions like add_systems. The ideal fix would be to accept functions returning ! (or rather, not returning), but this is blocked on the stabilisation of the ! type itself, which is not done.

The "simple" fix would be to add an explicit -> () to system signatures (e.g., || { todo!() } becomes || -> () { todo!() }). However, this is also banned, as there is an existing lint which (IMO, incorrectly) marks this as an unnecessary annotation.

So, the "fix" (read: workaround) is to put these kinds of || -> ! { ... } closuers into variables and give the variable an explicit type (e.g., fn()).

// Valid
let system: fn() = || todo!("Not implemented yet!");
app.add_systems(..., system);

// Invalid
app.add_systems(..., || todo!("Not implemented yet!"));

Temporary Variable Lifetimes

The order in which temporary variables are dropped has changed. The simple fix here is usually to just assign temporaries to a named variable before use.

gen is a keyword

We can no longer use the name gen as it is reserved for a future generator syntax. This involved replacing uses of the name gen with r#gen (the raw-identifier syntax).

Formatting has changed

Use statements have had the order of imports changed, causing a substantial +/-3,000 diff when applied. For now, I have opted-out of this change by amending rustfmt.toml

style_edition = "2021"

This preserves the original formatting for now, reducing the size of this PR. It would be a simple followup to update this to 2024 and run cargo fmt.

New use<> Opt-Out Syntax

Lifetimes are now implicitly included in RPIT types. There was a handful of instances where it needed to be added to satisfy the borrow checker, but there may be more cases where it should be added to avoid breakages in user code.

MyUnitStruct { .. } is an invalid pattern

Previously, you could match against unit structs (and unit enum variants) with a { .. } destructuring. This is no longer valid.

Pretty much every use of ref and mut are gone

Pattern binding has changed to the point where these terms are largely unused now. They still serve a purpose, but it is far more niche now.

iter::repeat(...).take(...) is bad

New lint recommends using the more explicit iter::repeat_n(..., ...) instead.

Migration Guide

The lifetimes of functions using return-position impl-trait (RPIT) are likely more conservative than they had been previously. If you encounter lifetime issues with such a function, please create an issue to investigate the addition of + use<...>.

Notes

• Check the individual commits for a clearer breakdown for what actually changed.

[github-actions]

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

[bushrat011899]

I've marked this PR as controversial because there is active debate around whether this should be done crate-by-crate, or some other approach. I don't believe the goal of using Rust 2024 is controversial at all.

[mockersf]

removing the controversial tag, this PR is already done and almost ready, let's not block on that as we don't have an SME matching this PR

[chescock]

Looks good! And today I learned about repeat_n and div_ceil.

[chescock]

I still think these would be clearer as named functions. Converting to a fn pointer adds a layer of indirection and wouldn't work if it took system params.

... But we don't have params here, and we hardly need to worry about an extra indirect jump when calling a function that always panics, so it's really not important. :)

[bushrat011899]

Agreed! I'm just going to leave it as-is because I definitely would prefer that we actually support |...| -> ! closures as systems. It'll make the eventual PR that adds that support more explicit in its benefits too.

[mockersf]

@bushrat011899 this has some conflicts from #17840. Could you resolve them?

[bushrat011899]

@mockersf Merged and CI is green!

[bushrat011899]

@mockersf Issue was caused by the use of #[no_mangle] within #[bevy_main] on mobile platforms, as in Rust Edition 2024, no_mangle is unsafe. I've added a safety comment but left a TODO around potentially making bevy_main itself unsafe (if that's even possible) or trying to strengthen its guards to make it safe to call.

I don't have a setup locally for checking this resolves the issue in CI, but it should be clear to merge now.