…traviscross

don't apply temporary lifetime extension rules to non-extended `super let`

Reference PR: rust-lang/reference#1980

This changes the semantics for `super let` (and macros implemented in terms of it, such as `pin!`, `format_args!`, `write!`, and `println!`) as suggested by ````@theemathas```` in rust-lang/rust#145784 (comment), making `super let` initializers only count as [extending expressions](https://doc.rust-lang.org/nightly/reference/destructors.html#extending-based-on-expressions) when the `super let` itself is within an extending block. Since `super let` initializers aren't temporary drop scopes, their temporaries outside of inner temporary scopes are effectively always extended, even when not in extending positions; this only affects two cases as far as I can tell:
- Block tail expressions in Rust 2024. This PR makes `f(pin!({ &temp() }))` drop `temp()` at the end of the block in Rust 2024, whereas previously it would live until after the call to `f` because syntactically the `temp()` was in an extending position as a result of `super let` in `pin!`'s expansion.
- `super let` nested within a non-extended `super let` is no longer extended. i.e. a normal `let` is required to treat `super let`s as extending (in which case nested `super let`s will also be extending).

Closes rust-lang/rust#145784

This is a breaking change. Both static and dynamic semantics are affected. The most likely breakage is for programs to stop compiling, but it's technically possible for drop order to silently change as well (as in rust-lang/rust#145784). Since this affects stable macros, it probably would need a crater run.

Nominating for discussion alongside rust-lang/rust#145784: ````@rustbot```` label +I-lang-nominated +I-libs-api-nominated

Tracking issue for `super let`: rust-lang/rust#139076

Rollup merge of #146898 - rustbot:docs-update, r=ehuss

Update books

## rust-lang/book

1 commits in 3e9dc46aa563ca0c53ec826c41b05f10c5915925..33f1af40cc44dde7e3e892f7a508e6f427d2cbc6
2025-09-15 16:10:14 UTC to 2025-09-15 16:10:14 UTC

- Release trpl 0.3 (rust-lang/book#4505)

## rust-lang/reference

9 commits in b3ce60628c6f55ab8ff3dba9f3d20203df1c0dee..cc7247d8dfaef4c39000bb12c55c32ba5b5ba976
2025-09-20 10:26:26 UTC to 2025-09-08 18:07:29 UTC

- Document temporary scoping for destructuring assignments (rust-lang/reference#1992)
- Specify lifetime extension of `pin!` and `format_args!` arguments (rust-lang/reference#1980)
- update for more ABIs supporting c-variadics (rust-lang/reference#1936)
- Fix incorrect span tag (rust-lang/reference#1995)
- Remove strike attribute (rust-lang/reference#1997)
- Specify the target limits for target-specific ABIs (rust-lang/reference#2000)
- Remove tuple index carve out (rust-lang/reference#1966)
- Enable folding of chapter listing in navigation sidebar (rust-lang/reference#1988)
- Add support to grammar for single line comments (rust-lang/reference#1993)

## rust-lang/rust-by-example

1 commits in dd26bc8e726dc2e73534c8972d4dccd1bed7495f..2c9b490d70e535cf166bf17feba59e594579843f
2025-09-18 22:28:52 UTC to 2025-09-18 22:28:52 UTC

- Update unit testing output for additional test (rust-lang/rust-by-example#1958)

…joboet

stdlib docs: document lifetime extension for `format_args!`'s arguments

Since rust-lang#140748 is stable and rust-lang#92698 is closed, the section about `format_args!`'s argument lifetime limitation is outdated. I've updated it to point to the Reference docs, which will specify lifetime extension rules for builtin macros once rust-lang/reference#1980 or equivalent is merged.

I've also taken the liberty of updating one of the doctests to assign the result of `format_args!` to a variable, both to provide an example and because I think it reads a little better.

r? `@m-ou-se`

Rollup merge of #145943 - dianne:format-args-assign-docs, r=joboet

stdlib docs: document lifetime extension for `format_args!`'s arguments

Since #140748 is stable and #92698 is closed, the section about `format_args!`'s argument lifetime limitation is outdated. I've updated it to point to the Reference docs, which will specify lifetime extension rules for builtin macros once rust-lang/reference#1980 or equivalent is merged.

I've also taken the liberty of updating one of the doctests to assign the result of `format_args!` to a variable, both to provide an example and because I think it reads a little better.

r? `@m-ou-se`

…joboet

stdlib docs: document lifetime extension for `format_args!`'s arguments

Since rust-lang#140748 is stable and rust-lang#92698 is closed, the section about `format_args!`'s argument lifetime limitation is outdated. I've updated it to point to the Reference docs, which will specify lifetime extension rules for builtin macros once rust-lang/reference#1980 or equivalent is merged.

I've also taken the liberty of updating one of the doctests to assign the result of `format_args!` to a variable, both to provide an example and because I think it reads a little better.

r? `@m-ou-se`

…traviscross

don't apply temporary lifetime extension rules to non-extended `super let`

Reference PR: rust-lang/reference#1980

This changes the semantics for `super let` (and macros implemented in terms of it, such as `pin!`, `format_args!`, `write!`, and `println!`) as suggested by ````@theemathas```` in rust-lang/rust#145784 (comment), making `super let` initializers only count as [extending expressions](https://doc.rust-lang.org/nightly/reference/destructors.html#extending-based-on-expressions) when the `super let` itself is within an extending block. Since `super let` initializers aren't temporary drop scopes, their temporaries outside of inner temporary scopes are effectively always extended, even when not in extending positions; this only affects two cases as far as I can tell:
- Block tail expressions in Rust 2024. This PR makes `f(pin!({ &temp() }))` drop `temp()` at the end of the block in Rust 2024, whereas previously it would live until after the call to `f` because syntactically the `temp()` was in an extending position as a result of `super let` in `pin!`'s expansion.
- `super let` nested within a non-extended `super let` is no longer extended. i.e. a normal `let` is required to treat `super let`s as extending (in which case nested `super let`s will also be extending).

Closes rust-lang/rust#145784

This is a breaking change. Both static and dynamic semantics are affected. The most likely breakage is for programs to stop compiling, but it's technically possible for drop order to silently change as well (as in rust-lang/rust#145784). Since this affects stable macros, it probably would need a crater run.

Nominating for discussion alongside rust-lang/rust#145784: ````@rustbot```` label +I-lang-nominated +I-libs-api-nominated

Tracking issue for `super let`: rust-lang/rust#139076

…jackh726,traviscross

don't apply temporary lifetime extension rules to non-extended `super let`

Reference PR: rust-lang/reference#1980

This changes the semantics for `super let` (and macros implemented in terms of it, such as `pin!`, `format_args!`, `write!`, and `println!`) as suggested by ````@theemathas```` in rust-lang#145784 (comment), making `super let` initializers only count as [extending expressions](https://doc.rust-lang.org/nightly/reference/destructors.html#extending-based-on-expressions) when the `super let` itself is within an extending block. Since `super let` initializers aren't temporary drop scopes, their temporaries outside of inner temporary scopes are effectively always extended, even when not in extending positions; this only affects two cases as far as I can tell:
- Block tail expressions in Rust 2024. This PR makes `f(pin!({ &temp() }))` drop `temp()` at the end of the block in Rust 2024, whereas previously it would live until after the call to `f` because syntactically the `temp()` was in an extending position as a result of `super let` in `pin!`'s expansion.
- `super let` nested within a non-extended `super let` is no longer extended. i.e. a normal `let` is required to treat `super let`s as extending (in which case nested `super let`s will also be extending).

Closes rust-lang#145784

This is a breaking change. Both static and dynamic semantics are affected. The most likely breakage is for programs to stop compiling, but it's technically possible for drop order to silently change as well (as in rust-lang#145784). Since this affects stable macros, it probably would need a crater run.

Nominating for discussion alongside rust-lang#145784: ````@rustbot```` label +I-lang-nominated +I-libs-api-nominated

Tracking issue for `super let`: rust-lang#139076

…jackh726,traviscross

don't apply temporary lifetime extension rules to non-extended `super let`

Reference PR: rust-lang/reference#1980

This changes the semantics for `super let` (and macros implemented in terms of it, such as `pin!`, `format_args!`, `write!`, and `println!`) as suggested by ````@theemathas```` in rust-lang#145784 (comment), making `super let` initializers only count as [extending expressions](https://doc.rust-lang.org/nightly/reference/destructors.html#extending-based-on-expressions) when the `super let` itself is within an extending block. Since `super let` initializers aren't temporary drop scopes, their temporaries outside of inner temporary scopes are effectively always extended, even when not in extending positions; this only affects two cases as far as I can tell:
- Block tail expressions in Rust 2024. This PR makes `f(pin!({ &temp() }))` drop `temp()` at the end of the block in Rust 2024, whereas previously it would live until after the call to `f` because syntactically the `temp()` was in an extending position as a result of `super let` in `pin!`'s expansion.
- `super let` nested within a non-extended `super let` is no longer extended. i.e. a normal `let` is required to treat `super let`s as extending (in which case nested `super let`s will also be extending).

Closes rust-lang#145784

This is a breaking change. Both static and dynamic semantics are affected. The most likely breakage is for programs to stop compiling, but it's technically possible for drop order to silently change as well (as in rust-lang#145784). Since this affects stable macros, it probably would need a crater run.

Nominating for discussion alongside rust-lang#145784: ````@rustbot```` label +I-lang-nominated +I-libs-api-nominated

Tracking issue for `super let`: rust-lang#139076

…traviscross

don't apply temporary lifetime extension rules to non-extended `super let`

Reference PR: rust-lang/reference#1980

This changes the semantics for `super let` (and macros implemented in terms of it, such as `pin!`, `format_args!`, `write!`, and `println!`) as suggested by ````@theemathas```` in rust-lang/rust#145784 (comment), making `super let` initializers only count as [extending expressions](https://doc.rust-lang.org/nightly/reference/destructors.html#extending-based-on-expressions) when the `super let` itself is within an extending block. Since `super let` initializers aren't temporary drop scopes, their temporaries outside of inner temporary scopes are effectively always extended, even when not in extending positions; this only affects two cases as far as I can tell:
- Block tail expressions in Rust 2024. This PR makes `f(pin!({ &temp() }))` drop `temp()` at the end of the block in Rust 2024, whereas previously it would live until after the call to `f` because syntactically the `temp()` was in an extending position as a result of `super let` in `pin!`'s expansion.
- `super let` nested within a non-extended `super let` is no longer extended. i.e. a normal `let` is required to treat `super let`s as extending (in which case nested `super let`s will also be extending).

Closes rust-lang/rust#145784

This is a breaking change. Both static and dynamic semantics are affected. The most likely breakage is for programs to stop compiling, but it's technically possible for drop order to silently change as well (as in rust-lang/rust#145784). Since this affects stable macros, it probably would need a crater run.

Nominating for discussion alongside rust-lang/rust#145784: ````@rustbot```` label +I-lang-nominated +I-libs-api-nominated

Tracking issue for `super let`: rust-lang/rust#139076

…traviscross

don't apply temporary lifetime extension rules to non-extended `super let`

Reference PR: rust-lang/reference#1980

This changes the semantics for `super let` (and macros implemented in terms of it, such as `pin!`, `format_args!`, `write!`, and `println!`) as suggested by ````@theemathas```` in rust-lang/rust#145784 (comment), making `super let` initializers only count as [extending expressions](https://doc.rust-lang.org/nightly/reference/destructors.html#extending-based-on-expressions) when the `super let` itself is within an extending block. Since `super let` initializers aren't temporary drop scopes, their temporaries outside of inner temporary scopes are effectively always extended, even when not in extending positions; this only affects two cases as far as I can tell:
- Block tail expressions in Rust 2024. This PR makes `f(pin!({ &temp() }))` drop `temp()` at the end of the block in Rust 2024, whereas previously it would live until after the call to `f` because syntactically the `temp()` was in an extending position as a result of `super let` in `pin!`'s expansion.
- `super let` nested within a non-extended `super let` is no longer extended. i.e. a normal `let` is required to treat `super let`s as extending (in which case nested `super let`s will also be extending).

Closes rust-lang/rust#145784

This is a breaking change. Both static and dynamic semantics are affected. The most likely breakage is for programs to stop compiling, but it's technically possible for drop order to silently change as well (as in rust-lang/rust#145784). Since this affects stable macros, it probably would need a crater run.

Nominating for discussion alongside rust-lang/rust#145784: ````@rustbot```` label +I-lang-nominated +I-libs-api-nominated

Tracking issue for `super let`: rust-lang/rust#139076