Rustc pull update #2526
Merged
Rustc pull update #2526
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![workflows-rustc-dev-guide[bot]](https://app.smartcontext.ai/default/https://avatars.githubusercontent.com/u/5430905?s=60&v=4){kind=small}
Some `let chains` clean-up Not sure if this kind of clean-up is welcoming because of size, but I decided to try out one r? compiler
Add `core::mem::DropGuard`
## 1.0 Summary
This PR introduces a new type `core::mem::DropGuard` which wraps a value and runs a closure when the value is dropped.
```rust
use core::mem::DropGuard;
// Create a new guard around a string that will
// print its value when dropped.
let s = String::from("Chashu likes tuna");
let mut s = DropGuard::new(s, |s| println!("{s}"));
// Modify the string contained in the guard.
s.push_str("!!!");
// The guard will be dropped here, printing:
// "Chashu likes tuna!!!"
```
## 2.0 Motivation
A number of programming languages include constructs like `try..finally` or `defer` to run code as the last piece of a particular sequence, regardless of whether an error occurred. This is typically used to clean up resources, like closing files, freeing memory, or unlocking resources. In Rust we use the `Drop` trait instead, allowing us to [never having to manually close sockets](https://blog.skylight.io/rust-means-never-having-to-close-a-socket/).
While `Drop` (and RAII in general) has been working incredibly well for Rust in general, sometimes it can be a little verbose to setup. In particular when upholding invariants are local to functions, having a quick inline way to setup an `impl Drop` can be incredibly convenient. We can see this in use in the Rust stdlib, which has a number of private `DropGuard` impls used internally:
- [library/alloc/src/vec/drain.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/vec/drain.rs#L177)
- [library/alloc/src/boxed/thin.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/boxed/thin.rs#L362)
- [library/alloc/src/slice.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/slice.rs#L413)
- [library/alloc/src/collections/linked_list.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/collections/linked_list.rs#L1135)
- [library/alloc/src/collections/binary_heap/mod.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/collections/binary_heap/mod.rs#L1816)
- [library/alloc/src/collections/btree/map.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/collections/btree/map.rs#L1715)
- [library/alloc/src/collections/vec_deque/drain.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/collections/vec_deque/drain.rs#L95)
- [library/alloc/src/vec/into_iter.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/vec/into_iter.rs#L488)
- [library/std/src/os/windows/process.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/std/src/os/windows/process.rs#L320)
- [tests/ui/process/win-proc-thread-attributes.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/tests/ui/process/win-proc-thread-attributes.rs#L17)
## 3.0 Design
This PR implements what can be considered about the simplest possible design:
1. A single type `DropGuard` which takes both a generic type `T` and a closure `F`.
2. `Deref` + `DerefMut` impls to make it easy to work with the `T` in the guard.
3. An `impl Drop` on the guard which calls the closure `F` on drop.
4. An inherent `fn into_inner` which takes the type `T` out of the guard without calling the closure `F`.
Notably this design does not allow divergent behavior based on the type of drop that has occurred. The [`scopeguard` crate](https://docs.rs/scopeguard/latest/scopeguard/index.html) includes additional `on_success` and `on_onwind` variants which can be used to branch on unwind behavior instead. However [in a lot of cases](rust-lang/rust#143612 (comment)) this doesn’t seem necessary, and using the arm/disarm pattern seems to provide much the same functionality:
```rust
let guard = DropGuard::new((), |s| ...); // 1. Arm the guard
other_function(); // 2. Perform operations
guard.into_inner(); // 3. Disarm the guard
```
`DropGuard` combined with this pattern seems like it should cover the vast majority of use cases for quick, inline destructors. It certainly seems like it should cover all existing uses in the stdlib, as well as all existing uses in crates like [hashbrown](https://github.com/search?q=repo%3Arust-lang%2Fhashbrown%20guard&type=code).
## 4.0 Acknowledgements
This implementation is based on the [mini-scopeguard crate](https://github.com/yoshuawuyts/mini-scopeguard) which in turn is based on the [scopeguard crate](https://docs.rs/scopeguard). The implementations only differ superficially; because of the nature of the problem there is only really one obvious way to structure the solution. And the scopeguard crate got that right!
## 5.0 Conclusion
This PR adds a new type `core::mem::DropGuard` to the stdlib which adds a small convenience helper to create inline destructors with. This would bring the majority of the functionality of the `scopeguard` crate into the stdlib, which is the [49th most downloaded crate](https://crates.io/crates?sort=downloads) on crates.io (387 million downloads).
Given the actual implementation of `DropGuard` is only around 60 lines, it seems to hit that sweet spot of low-complexity / high-impact that makes for a particularly efficient stdlib addition. Which is why I’m putting this forward for consideration; thanks!
…=Mark-Simulacrum Move dist-apple-various from x86_64 to aarch64 `macos-13` is going away soonish.
rustc-dev-guide subtree update Subtree update of `rustc-dev-guide` to e19866a. Created using https://github.com/rust-lang/josh-sync. r? `````@ghost`````
Raw Pointers are Constant PatKinds too
raw pointers can be matched on with a const pattern:
```rust
const FOO: *const u8 = core::ptr::null();
fn foo(a: *const u8) {
match a {
FOO => (),
_ => todo!(),
}
}
```
as far as I can tell this is represented with a `PatKind::Constant`: https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/thir/pattern/const_to_pat.rs#L333-L337
fixed typo chunks->as_chunks Fixes rust-lang/rust#144555 info-: fix typo chunks -> as_chunks This now take us to as_chunks page when clicking on as_chunks link and not to chunks . Thanks .
Ensure correct aligement of rustc_hir::Lifetime on platforms with lower default alignments. The compiler relies on `hir::Lifetime` being aligned to at least 4 bytes(for the purposes of pointer tagging). However, on some systems(like m68k) with lower alignment requirements(eg. usize / u32 aligned to 2 bytes),`hir::Lifetime` will be aligned to only 2 bytes. This causes the compilation to fail on those systems - a const assert in the compiler fails. This PR makes the aligement requriement of hir::Lifetime explict. This has no effect on platforms where that already is the case(repr align can only raise alignment), but ensures the alignment will stay correct no matter what.
fix `Atomic*::as_ptr` wording r? `````@RalfJung````` cc rust-lang/rust#144072
coverage: Regression test for "function name is empty" bug Regression test for rust-lang/rust#141577, which was triggered by rust-lang/rust#144298. The bug was triggered by a particular usage of the `?` try operator in a proc-macro expansion. Thanks to lqd for the minimization at rust-lang/rust#144571 (comment). --- I have manually verified that reverting the relevant follow-up fixes (rust-lang/rust#144480 and rust-lang/rust#144530) causes this test to reproduce the bug: ```sh git revert -m1 8aa3d41b8527f9f78e0f2459b50a6e13aea35144 c462895a6f0b463ff0c1c1db2a3a654d7e5976c7 ``` --- r? compiler
Rollup of 10 pull requests Successful merges: - rust-lang/rust#143883 (Add `--link-targets-dir` argument to linkchecker) - rust-lang/rust#144236 (Add `core::mem::DropGuard`) - rust-lang/rust#144367 (Move dist-apple-various from x86_64 to aarch64) - rust-lang/rust#144539 (constify with_exposed_provenance) - rust-lang/rust#144569 (rustc-dev-guide subtree update) - rust-lang/rust#144573 (Raw Pointers are Constant PatKinds too) - rust-lang/rust#144575 (fixed typo chunks->as_chunks) - rust-lang/rust#144578 (Ensure correct aligement of rustc_hir::Lifetime on platforms with lower default alignments.) - rust-lang/rust#144582 (fix `Atomic*::as_ptr` wording) - rust-lang/rust#144616 (coverage: Regression test for "function name is empty" bug) r? `@ghost` `@rustbot` modify labels: rollup
Complete span AST lowering. r? `@ghost`
LoongArch64 LSX fast-path for `str.contains(&str)` Benchmark results with LLVM 21 on LA664: ``` OLD: test bench_is_contained_in ... bench: 43.63 ns/iter (+/- 0.04) NEW: test bench_is_contained_in ... bench: 12.81 ns/iter (+/- 0.01) ```
Pick the largest niche even if the largest niche is wrapped around fixes rust-lang/rust#144388 r? `@scottmcm`
Free disk space on Windows 2025 runners I've managed to reduce the time deletion takes by: - Using powershell, which is generally faster for filesystem operations than msys2 - Performing deletions concurrently then waiting for them all to complete It still takes 2-10 mins but that's not too bad.
Verify llvm-needs-components are not empty and match the --target value I recently discovered a test with an empty `llvm-needs-components` entry (fixed in rust-lang/rust#143979) which meant that it didn't work correctly when building Rust with a limited set of LLVM targets. This change makes a pair of improvements to prevent this issue from creeping in again: * When parsing directives with values, `compiletest` will now raise an error if there is an empty value. * Improved the `target_specific_tests` tidy checker to map targets to LLVM components, to verify that any existing `llvm-needs-components` contains the target being used. I also fixed all the issues flagged by the improved tidy checker.
Add method `find_ancestor_not_from_macro` and `find_ancestor_not_from_extern_macro` to supersede `find_oldest_ancestor_in_same_ctxt` As I was using it, I realized that the function is supposed to walk up to expand the chain? This seems to be the opposite of what I understood. r? `@jieyouxu`
Remove `hello_world` directory Move `tests/ui/hello_world/main.rs` and retire the single-file `tests/ui/hello_world/` directory. Part of rust-lang/rust#133895. r? `@jieyouxu`
compiletest: Move directive names back into a separate file This list no longer needs to be included in multiple crates, but having the list in its own file makes it easier to find and update when necessary. As discussed at rust-lang/rust#143850 (comment).
Make sure to account for the right item universal regions in borrowck Fixes rust-lang/rust#144608. The ICE comes from a mismatch between the liberated late bound regions (i.e. "`ReLateParam`"s) that come from promoting closure outlives, and the regions we have in our region vid mapping from `UniversalRegions`. When building `UniversalRegions`, we end up using the liberated regions from the binder of the closure's signature: https://github.com/rust-lang/rust/blob/c8bb4e8a126cf38cff70cea488a3a423a5321954/compiler/rustc_borrowck/src/universal_regions.rs#L521 Notably, this signature may be anonymized if the closure signature being deduced comes from an external constraints: https://github.com/rust-lang/rust/blob/c8bb4e8a126cf38cff70cea488a3a423a5321954/compiler/rustc_hir_typeck/src/closure.rs#L759-L762 This is true in the test file I committed, where the signature is influenced by the `impl FnMut(&mut ())` RPIT. However, when promoting a type outlives constraint we end up creating a late bound lifetime mapping that disagrees with those liberated late bound regions we constructed in `UniversalRegions`: https://github.com/rust-lang/rust/blob/c8bb4e8a126cf38cff70cea488a3a423a5321954/compiler/rustc_borrowck/src/universal_regions.rs#L299 Specifically, in `for_each_late_bound_region_in_item` (which is called by `for_each_late_bound_region_in_recursive_scope`), we were using `tcx.late_bound_vars` which uses the late bound regions *from the HIR*. This query both undercounts the late bound regions (e.g. those that end up being deduced from bounds), and also doesn't account for the fact that we anonymize them in the signature as mentioned above. https://github.com/rust-lang/rust/blob/c8bb4e8a126cf38cff70cea488a3a423a5321954/compiler/rustc_borrowck/src/universal_regions.rs#L977 This PR fixes that function to use the *correct signature*, which properly considers the bound vars that come from deducing the signature of the closure, and which comes from the closure's args from the `type_of` query.
…r=jieyouxu [test][run-make] add needs-llvm-components Add some constraints to run-make tests that require specific target support and will fail without them.
Rollup of 6 pull requests Successful merges: - rust-lang/rust#144042 (Verify llvm-needs-components are not empty and match the --target value) - rust-lang/rust#144268 (Add method `find_ancestor_not_from_macro` and `find_ancestor_not_from_extern_macro` to supersede `find_oldest_ancestor_in_same_ctxt`) - rust-lang/rust#144411 (Remove `hello_world` directory) - rust-lang/rust#144662 (compiletest: Move directive names back into a separate file) - rust-lang/rust#144666 (Make sure to account for the right item universal regions in borrowck) - rust-lang/rust#144668 ([test][run-make] add needs-llvm-components) r? `@ghost` `@rustbot` modify labels: rollup
Remove eval_always from check_private_in_public. This PR attempts to avoid re-computing `check_private_in_public` query. First by marking the query as non-`eval_always`, and by reducing the amount of accesses to HIR as much as possible. Latest perf rust-lang/rust#116316 (comment) shows that we manage it. The cost is extra dep-graph bookkeeping.
uniquify root goals during HIR typeck We need to rely on region identity to deal with hangs such as rust-lang/trait-system-refactor-initiative#210 and to keep the current behavior of `fn try_merge_responses`. This is a problem as borrowck starts by replacing each *occurrence* of a region with a unique inference variable. This frequently splits a single region during HIR typeck into multiple distinct regions. As we assume goals to always succeed during borrowck, relying on two occurances of a region being identical during HIR typeck causes ICE. See the now fixed examples in rust-lang/trait-system-refactor-initiative#27 and rust-lang/rust#139409. We've previously tried to avoid this issue by always *uniquifying* regions when canonicalizing goals. This prevents caching subtrees during canonicalization which resulted in hangs for very large types. People rely on such types in practice, which caused us to revert our attempt to reinstate `#[type_length_limit]` in rust-lang/rust#127670. The complete list of changes here: - rust-lang/rust#107981 - rust-lang/rust#110180 - rust-lang/rust#114117 - rust-lang/rust#130821 After more consideration, all occurrences of such large types need to happen outside of typeck/borrowck. We know this as we already walk over all types in the MIR body when replacing their regions with nll vars. This PR therefore enables us to rely on region identity inside of the trait solver by exclusively **uniquifying root goals during HIR typeck**. These are the only goals we assume to hold during borrowck. This is insufficient as type inference variables may "hide" regions we later uniquify. Because of this, we now stash proven goals which depend on inference variables in HIR typeck and reprove them after writeback. This closes rust-lang/trait-system-refactor-initiative#127. This was originally part of rust-lang/rust#144258 but I've moved it into a separate PR. While I believe we need to rely on region identity to fix the performance issues in some way, I don't know whether rust-lang/rust#144258 is the best approach to actually do so. Regardless of how we deal with the hangs however, this change is necessary and desirable regardless. r? `@compiler-errors` or `@BoxyUwU`
This updates the rust-version file to 32e7a4b92b109c24e9822c862a7c74436b50e564.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 32e7a4b92b109c24e9822c862a7c74436b50e564 Filtered ref: d39f347 This merge was created using https://github.com/rust-lang/josh-sync.
|
Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using |
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Latest update from rustc.