Prepare standard library for Rust 2024 migration#136983
Conversation
rustbot
added
O-hermit
There was a problem hiding this comment.
The changes here mostly look good to me. However, rand marked Rng::gen deprecated and introduced Rng::random to replace it in version 0.9, released 2 weeks ago. If bumping rand isn't terribly painful (seems pretty compatible), I think it might make sense to do that separately first, which would mean updating the existing uses of gen. Rather than r#gen now and then needing to update again to avoid the deprecation warning.
| let _ = unsafe { Pin::new(&mut 2).get_unchecked_mut() }; | ||
| let r = &mut 2; | ||
| let _ = unsafe { Pin::new(r).get_unchecked_mut() }; |
There was a problem hiding this comment.
Out of curiosity, what makes this necessary?
There was a problem hiding this comment.
Tail expression scope changes. In 2024 the temporary &mut 2 would go out of scope at the end of the unsafe block, but get_unchecked_mut is returning a reference tied to it. In 2021, the temporary is extended to the end of the statement.
There was a problem hiding this comment.
You know, thinking about this more, I decided it would be a little less weird to write it as:
unsafe {
let _ = Pin::new(&mut 2).get_unchecked_mut();
}
ehuss
force-pushed
the
misc-2024-prep
branch
from
bcdcf7a to
3c25135
Compare
rustbot
added
A-tidy
|
The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging. These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
Sure, I added a commit that updates rand instead. |
|
I realized I missed a commit for deprecated_safe_2024, so I added it (0f80413). |
A small workaround for rust-lang#136899, rustdoc's invalid_rust_codeblocks was not handling this well in 2024. This may be needed when migrating to 2024 when building with stage0.
This generates a warning of irrefutable patterns. I decided to slightly tweak the example so the closure returns unit, since the intent wasn't to show the weird behavior of returning `!`.
ehuss
force-pushed
the
misc-2024-prep
branch
from
0f80413 to
ef20a1b
Compare
| "windows_x86_64_gnullvm", | ||
| "windows_x86_64_msvc", | ||
| "zerocopy", | ||
| "zerocopy-derive", |
There was a problem hiding this comment.
Where is zerocopy-derive coming from? We have default features off for rand so it shouldn't be through there, I'm not seeing it pop up anywhere in cargo tree for the library.
rand is only a dev dependency so it doesn't really matter, the extra items are just surprising.
There was a problem hiding this comment.
I'm guessing it is getting confused by this unusual pinning approach in zerocopy:
[target."cfg(any())".dependencies.zerocopy-derive]
version = "=0.8.17"
The dependency list here unconditionally includes all target dependencies.
There was a problem hiding this comment.
Huh, that is interesting. The deps appear in library/Cargo.lock though, I guess the pinning causes them to show up there even if they aren't used?
There was a problem hiding this comment.
Yea, cargo does the same thing. Cargo.lock is generated as if all the [target] tables are included unconditionally.
I don't think I've ever seen someone use this approach of cfg(any()), it's quite interesting.
|
Can we hold off on the rand update? See discussion in #136395 around the binaries that adds to the compiler deps (if only actually linked in on wasm) |
This PR shouldn't bring in wit-bindgen, as this uses |
|
Sounds good, not a concern then. Thanks! |
|
@bors r=tgross35 rollup |
bors
added
S-waiting-on-bors
5 participants
This includes a variety of commits preparing the standard library for migration to Rust 2024.
The actual migration is blocked on a few things, so I wanted to get this out of the way in a relatively digestable PR.