rustfmt: Also allow bool literals as first item of let chain
This is a functional cherry-pick of https://github.com/rust-lang/rustfmt/pull/6492
I'm bringing this change over directly as the subtree sync is taking more effort than anticipated (some unrelated r-l/rustfmt changes need to be reverted before we perform the full sync) and we need to ensure that rustfmt behavior accounts with the final style guide rules as part of let chain stabilization.
r? ````@ghost````
CI: rfl: move job forward to Linux v6.15-rc4
A hopefully routine upgrade to Linux v6.15-rc4!
r? `````@lqd````` `````@Kobzol`````
try-job: x86_64-rust-for-linux
`````@rustbot````` label A-rust-for-linux
`````@bors````` try
Add `rust.debug-assertions-tools` option
Before this PR, the two only options to configure the presence of debug assertions were the `rust.debug-assertions` and `rust.debug-assertions-std` options. The former applied to everything, and the latter allowed to override the setting just for the standard library. This combination of settings doesn't allow to enable debug assertions for the std and the compiler but not tools.
Some tools (like Cargo) are not really meant to be executed with debug assertions enabled, and in Ferrocene we hit some debug assertions in it that are exclusively meant for its test suite. We'd thus like to enable debug assertions everywhere but in tools.
This PR adds a `rust.debug-assertions-tools` setting that does exactly this.
compiletest: Remove the libtest-based executor and its dependency
Now that #140288 has landed and the new compiletest executor is used by default, we can now move forward with removing the libtest dependency from compiletest.
My hope is that after landing this, we can configure bootstrap to build compiletest with the pre-built stage0 library by default, instead of the in-tree stage0 library. That would give the stage0 redesign one less thing to worry about.
---
This PR has deliberately been kept small and simple, to make it easier to revert if necessary. Further cleanup can take palce after we're confident that it won't need to be reverted.
r? jieyouxu
Blocker for https://github.com/rust-lang/rust/pull/119899
allow deref patterns to move out of boxes
This adds a case to lower deref patterns on boxes using a built-in deref instead of a `Deref::deref` or `DerefMut::deref_mut` call: if `deref!(inner): Box<T>` is matching on place `place`, the inner pattern `inner` now matches on `*place` rather than a temporary. No longer needing to call a method also means it won't borrow the scrutinee in match arms. This allows for bindings in `inner` to move out of `*place`.
For comparison with box patterns, this uses the same MIR lowering but different THIR. Consequently, deref patterns on boxes are treated the same as any other deref patterns in match exhaustiveness analysis. Box patterns can't quite be implemented in terms of deref patterns until exhaustiveness checking for deref patterns is implemented (I'll open a PR for exhaustiveness soon!).
Tracking issue: #87121
r? ``@Nadrieril``
Rollup of 7 pull requests
Successful merges:
- #140056 (Fix a wrong error message in 2024 edition)
- #140220 (Fix detection of main function if there are expressions around it)
- #140249 (Remove `weak` alias terminology)
- #140316 (Introduce `BoxMarker` to improve pretty-printing correctness)
- #140347 (ci: clean more disk space in codebuild)
- #140349 (ci: use aws codebuild for the `dist-x86_64-linux` job)
- #140379 (rustc-dev-guide subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
Async drop codegen
Async drop implementation using templated coroutine for async drop glue generation.
Scopes changes to generate `async_drop_in_place()` awaits, when async droppable objects are out-of-scope in async context.
Implementation details:
https://github.com/azhogin/posts/blob/main/async-drop-impl.md
New fields in Drop terminator (drop & async_fut). Processing in codegen/miri must validate that those fields are empty (in full version async Drop terminator will be expanded at StateTransform pass or reverted to sync version). Changes in terminator visiting to consider possible new successor (drop field).
ResumedAfterDrop messages for panic when coroutine is resumed after it is started to be async drop'ed.
Lang item for generated coroutine for async function async_drop_in_place. `async fn async_drop_in_place<T>()::{{closure0}}`.
Scopes processing for generate async drop preparations. Async drop is a hidden Yield, so potentially async drops require the same dropline preparation as for Yield terminators.
Processing in StateTransform: async drops are expanded into yield-point. Generation of async drop of coroutine itself added.
Shims for AsyncDropGlueCtorShim, AsyncDropGlue and FutureDropPoll.
```rust
#[lang = "async_drop"]
pub trait AsyncDrop {
#[allow(async_fn_in_trait)]
async fn drop(self: Pin<&mut Self>);
}
impl Drop for Foo {
fn drop(&mut self) {
println!("Foo::drop({})", self.my_resource_handle);
}
}
impl AsyncDrop for Foo {
async fn drop(self: Pin<&mut Self>) {
println!("Foo::async drop({})", self.my_resource_handle);
}
}
```
First async drop glue implementation re-worked to use the same drop elaboration code as for sync drop.
`async_drop_in_place` changed to be `async fn`. So both `async_drop_in_place` ctor and produced coroutine have their lang items (`AsyncDropInPlace`/`AsyncDropInPlacePoll`) and shim instances (`AsyncDropGlueCtorShim`/`AsyncDropGlue`).
```
pub async unsafe fn async_drop_in_place<T: ?Sized>(_to_drop: *mut T) {
}
```
AsyncDropGlue shim generation uses `elaborate_drops::elaborate_drop` to produce drop ladder (in the similar way as for sync drop glue) and then `coroutine::StateTransform` to convert function into coroutine poll.
AsyncDropGlue coroutine's layout can't be calculated for generic T, it requires known final dropee type to be generated (in StateTransform). So, `templated coroutine` was introduced here (`templated_coroutine_layout(...)` etc).
Such approach overrides the first implementation using mixing language-level futures in https://github.com/rust-lang/rust/pull/121801.
