Fix CI for Rust 1.72

[rparrett]

Objective

Rust 1.72.0 is now stable.

Notes

• let-else formatting has arrived!

• I chose to allow explicit_iter_loop due to explicit_iter_loop: x.iter_mut() vs &mut *x rust-lang/rust-clippy#11074.

  We didn't hit any of the false positives that prevent compilation, but fixing this did produce a lot of the "symbol soup" mentioned, e.g. for image in &mut *image_events {.

  Happy to undo this if there's consensus the other way.

[cart]

Dang I really wanted one liners for cases like this:

[rparrett]

Dang I really wanted one liners for cases like this:

Might be fixable: https://github.com/rust-lang/rustfmt/blob/v1.6.0/Configurations.md#single_line_let_else_max_width

[rparrett]

I think that there must be some bug with single_line_let_else_max_width because even with it set very high, lots of seemingly narrow-enough lines get formatted on multiple lines.

edit: some discussion here: rust-lang/rustfmt#5849

[ickk]

Dang I really wanted one liners for cases like this:

@cart The style guide1 reads like it should just work as long as we remove the semicolon from after the return

Format the entire let-else statement on a single line if all the following are true:

• the entire statement is short
• the else block contains only a single-line expression and no statements
• the else block contains no comments
• the let statement components preceding the else block can be formatted on a single line

let Some(1) = opt else { return };

The reference2 grammar implies that any expression (including return expressions 3) which is followed by a semicolon becomes an ExpressionStatement, which would disqualify return; but not return.

Though it also says

An expression that consists of only a block expression or control flow expression, if used in a context where a statement is permitted, can omit the trailing semicolon. This can cause an ambiguity between it being parsed as a standalone statement and as a part of another expression; in this case, it is parsed as a statement

.. which makes it seem like sometimes expressions without a semicolon may be parsed as statements anyway, if they are a block or "control flow expression" (idk where that group is really defined).

[rparrett]

This reads like it should just work as long as we remove the semicolon from after the return

It seems like that helps in the case of else { return };, but fmt adds a semicolon inside the block in the case of e.g. else { return true; };

[ickk]

It seems like that helps in the case of else { return };, but fmt adds a semicolon inside the block in the case of e.g. else { return true; };

That seems like it would be caused by this "unstable" rustfmt option.. https://rust-lang.github.io/rustfmt/?version=v1.6.0&search=semi#trailing_semicolon
rust-lang/rustfmt#3378

[rparrett]

We seemingly can't set single_line_let_else_max_width greater than ~83 due to rust-lang/rustfmt#5404.

Doing so results in a spam of many lines of

`single_line_let_else_max_width` cannot have a value that exceeds `max_width`. `single_line_let_else_max_width` will be set to the same value as `max_width`

in the console while formatting.

[nicopap]

This needs to be merged ASAP