Rollup of 12 pull requests #144618
Closed
Rollup of 12 pull requests #144618
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
Signed-off-by: xizheyin <[email protected]>
To clarify what it does.
`macos-13` is going away soonish.
Co-authored-by: lcnr <[email protected]> Co-authored-by: Ralf Jung <[email protected]> Co-authored-by: waffle <[email protected]>
- Address Call for Testing review feedback - Address Affiliated work review feedback - Drop "stabilization is easy" part - Fix broken feature gate examples - Elaborate on stabilization report summarization aspects - Recommend waiting a bit for team nominations - Make Stabilization Template markdown copy friendly - Register stabilization report template - Drop unfinished sentence - Clarify stabilization report template is for language features - Add test coverage elaboration - Add UB checks / opt question - Amend test coverage explanation - Mention OSS nightly users
Let's revise both the new content in this PR as well as the remaining text in the relevant chapters so as to better describe our current processes related to language features and their stabilizations. For the new stabilization report template, based on reviewing its early use and well as reviewing earlier stabilization reports, we've revised it editorially and added questions designed to capture additional details to which we commonly want people to speak.
…er default alignments.
This updates the rust-version file to 2b5e239.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 2b5e239 Filtered ref: dde2393b3444ae8595633863f4395f526b1b7932 This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update
cleaning some "error pattern" text
…ulacrum
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#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!
…ieyouxu 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``
…ieyouxu Consolidate staging for `rustc_private` tools This PR continues bootstrap refactoring, this time by consolidating staging for `Mode::ToolRustc` tools. This refactoring was in the critical path of refactoring `test`/`dist`/`clippy`/`doc` steps, and getting rid of the rmeta/rlib sysroot copy, because tools are pervasive and they are being used for a lot of things in bootstrap. The main idea is to explicitly model the fact that a stage N `Mode::ToolRustc` tool always works with two different compilers: - Stage N-1 rustc (`build_compiler`) builds stage N rustc (`target_compiler`) - Rlib artifacts from stage N rustc are copied to the sysroot of stage N-1 rustc - Stage N-1 rustc builds the (stage N) tool itself, the tool links to the rlib artifacts of the stage N rustc Before, the code often used `compiler`, which meant sometimes the build compiler, sometimes the target compiler, and sometimes neither (looking at you, `download-rustc`). This is especially annoying when you get to a situation where you have an install step that invokes a dist step that invokes a tool build step, where *some* compiler is being propagated through, without it being clear what does that compiler represent. This refactoring hopefully makes that clearer and more explicit. It also gets rid of a few `builder.ensure(Rustc(...))` calls within bootstrap, which is always nice. `Rustdoc` needs to be handled a bit specially, because it acts as a compiler itself, I documented that in the changes. It wasn't practical to do these refactorings in multiple PRs, so I did it all in one PR. The meat of the change is 9ee6d1c. I tested manually that `x build rustdoc` and `x build miri` still works even with `download-rustc`, although I cannot promise any extra support for `download-rustc`, IMO we will just have to reimplement it from scratch in a different way. As usually, I did some drive-by refactorings to bootstrap, trying to document and clarify things, add more step metadata and tests. Best reviewed commit-by-commit (note that I renamed `link_compiler` to `target_compiler`, in accordance to the rest of bootstrap, in the last commit). r? ``@jieyouxu``
…-usage, r=Mark-Simulacrum Move dist-apple-various from x86_64 to aarch64 `macos-13` is going away soonish.
…ance, r=oli-obk constify with_exposed_provenance We allow `int as ptr` in const, so it only makes sense to also allow this function. Otherwise, `const fn` can't be ported to use the more explicit exposed provenance APIs. Note that as of today, `with_exposed_provenance` in const is equivalent to `without_provenance`. However, we probably don't want to promise that: if someone does `with_exposed_provenance(MMIO_ADDR)` in const and then uses that pointer at runtime, that is something we should ensure keeps working; if someone does the same with `without_provenance` then I would consider that UB. Tracking: rust-lang#144538 Cc ``@rust-lang/wg-const-eval`` ``@rust-lang/opsem``
rustc-dev-guide subtree update Subtree update of `rustc-dev-guide` to rust-lang/rustc-dev-guide@e19866a. Created using https://github.com/rust-lang/josh-sync. r? ``@ghost``
… r=lcnr
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#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 .
…rors 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#144072
rustbot
added
A-CI
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
The job Click to see the possible cause of the failure (guessed by this bot) |
bors
added
S-waiting-on-author
rustbot
removed
the
S-waiting-on-author
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.
Successful merges:
--link-targets-dirargument to linkchecker #143883 (Add--link-targets-dirargument to linkchecker)core::mem::DropGuard#144236 (Addcore::mem::DropGuard)find_ancestor_not_from_macroandfind_ancestor_not_from_extern_macroto supersedefind_oldest_ancestor_in_same_ctxt#144268 (Add methodfind_ancestor_not_from_macroandfind_ancestor_not_from_extern_macroto supersedefind_oldest_ancestor_in_same_ctxt)rustc_privatetools #144303 (Consolidate staging forrustc_privatetools)Atomic*::as_ptrwording #144582 (fixAtomic*::as_ptrwording)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup