# Objective
- Fixes#17960
## Solution
- Followed the [edition upgrade
guide](https://doc.rust-lang.org/edition-guide/editions/transitioning-an-existing-project-to-a-new-edition.html)
## 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.
```rust
/* 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](https://doc.rust-lang.org/std/primitive.never.html), 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()`).
```rust
// 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`
```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.
---------
Co-authored-by: François Mockers <francois.mockers@vleue.com>
Silence those [annoying rustfmt config warnings](https://github.com/bevyengine/bevy/pull/1499/checks?check_run_id=1950282111#step:5:66) that happen because we have unstable rustfmt options in `rustfmt.toml`, but we run it in stable on CI. Thanks to @Ratysz for [calling it out](https://github.com/bevyengine/bevy/pull/1499#issuecomment-783190586). 😄
The final approach we settled on was to comment out the unstable options in `rustfmt.toml`. Those who are using `nightly` may uncomment the unstable options locally if they wish. Once the options stabilize, we can uncomment them again.
We also decided that instead of fixing the alias, we would remove the alias entirely so that we do not introduce a custom `.cargo/config.toml` that would conflict with users' custom version of the same file. This means that instead of using a `cargo ci` alias you should use `cargo run -p ci` or `cargo run --package ci` instead.
<details><summary>Original Approach (abandoned)</summary>
<p>
_We decided **not** to go this way..._
In my quest to find a portable way to filter out the warnings I switched the library used to execute commands from `xshell` to `duct` (as advised by the `xshell` project itself when you want to do less simple things). This still uses the "xtask" pattern of using a cargo command alias and a rust project for what would have usually been done with a bash script (on posix), just a different helper library is being used internally.
NOTE 1: Also, thanks to some sleuthing by @DJMcNab we were able to fix the broken cargo alias. The issue turned out to be that `.cargo/config.toml` was being ignored because of `.gitignore`.
NOTE 2: This is a [known breaking change](https://github.com/bevyengine/bevy/pull/1309#discussion_r564023753) for anyone working on bevy who has their own local `.cargo/config.toml`.
</p>
</details>
