Rust 1.71.0 #47
Closed
Rust 1.71.0 #47
Conversation
This file contains 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: clundro <[email protected]>
I wrote these in a previous PR that I ended up withdrawing, so might as well submit them separately.
Co-authored-by: David Tolnay <[email protected]>
Improve internal field comments on `slice::Iter(Mut)` I wrote these in a previous PR that I ended up withdrawing, so might as well submit them separately. `@bors` rollup=always
`inline(always)` for `lt`/`le`/`ge`/`gt` on integers and floats I happened to notice one of these not getting inlined as part of `Range::next` in <https://rust.godbolt.org/z/4WKWWxj1G> ```rust bb1: { StorageLive(_5); _6 = &mut _4; StorageLive(_21); StorageLive(_14); StorageLive(_15); _15 = &((*_6).0: usize); StorageLive(_16); _16 = &((*_6).1: usize); _14 = <usize as PartialOrd>::lt(move _15, move _16) -> bb7; } ``` So since a call for something that's just one instruction is never the right choice, `#[inline(always)]` seems appropriate, like we have it on things like the rotate methods on integers.
…olnay Loosen `From<&[T]> for Box<[T]>` bound to `T: Clone` Also loosens `From<Cow<'_, [T]>> for Box<[T]>`'s bound. [Discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/From.3C.26.5BT.5D.3E.20impls.20consistency)
…r=jyn514 Remove unneeded function call in `core::option`. r? `@jyn514`
Rollup of 6 pull requests Successful merges: - #110118 (download-rustc: Give a better error message if artifacts can't be dowloaded) - #110631 (rustdoc: catch and don't blow up on impl Trait cycles) - #110732 (Make ConstProp some tests unit.) - #110996 (bootstrap: Fix compile error: unused-mut) - #110999 (Output some bootstrap messages on stderr) - #111000 (Remove unneeded function call in `core::option`.) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Tweak await span to not contain dot Fixes a discrepancy between method calls and await expressions where the latter are desugared to have a span that *contains* the dot (i.e. `.await`) but method call identifiers don't contain the dot. This leads to weird suggestions suggestions in borrowck -- see linked issue. Fixes #110761 This mostly touches a bunch of tests to tighten their `await` span.
update Miri r? `@ghost`
(`StructuralEq` is shallow for some reason...)
Make `mem::replace` simpler in codegen Since they'd mentioned more intrinsics for simplifying stuff recently, r? `@WaffleLapkin` This is a continuation of me looking at foundational stuff that ends up with more instructions than it really needs. Specifically I noticed this one because `Range::next` isn't MIR-inlining, and one of the largest parts of it is a `replace::<usize>` that's a good dozen instructions instead of the two it could be. So this means that `ptr::write` with a `Copy` type no longer generates worse IR than manually dereferencing (well, at least in LLVM -- MIR still has bonus pointer casts), and in doing so means that we're finally down to just the two essential `memcpy`s when emitting `mem::replace` for a large type, rather than the bonus-`alloca` and three `memcpy`s we emitted before this ([or the 6 we currently emit in 1.69 stable](https://rust.godbolt.org/z/67W8on6nP)). That said, LLVM does _usually_ manage to optimize the extra code away. But it's still nice for it not to have to do as much, thanks to (for example) not going through an `alloca` when `replace`ing a primitive like a `usize`. (This is a new intrinsic, but one that's immediately lowered to existing MIR constructs, so not anything that MIRI or the codegen backends or MIR semantics needs to do work to handle.)
Some of these relations were already mentioned in the text, but that Send is implemented for &mut impl Send was not mentioned, neither did the docs list when &T is Sync.
…, r=m-ou-se std docs: edit `PathBuf::set_file_name` example To make explicit that `set_file_name` might replace or remove the extension, not just the file stem. Also edit docs for `Path::with_file_name`, which calls `set_file_name`.
Add 64-bit `time_t` support on 32-bit glibc Linux to `set_times` Add support to `set_times` for 64-bit `time_t` on 32-bit glibc Linux platforms which have a 32-bit `time_t`. Split from #109773. Tracking issue: #98245
update wasi_clock_time_api ref. Closes #110809 >Preview0 corresponded to the import module name wasi_unstable. It was also called snapshot_0 in some places. It was short-lived, and the changes to preview1 were minor, so the focus here is on preview1. we use the `preview1` doc according to the above quote form [WASI legacy Readme](https://github.com/WebAssembly/WASI/blob/main/legacy/README.md) .
Make sure the implementation of TcpStream::as_raw_fd is fully inlined
Currently the following function:
```rust
use std::os::fd::{AsRawFd, RawFd};
use std::net::TcpStream;
pub fn as_raw_fd(socket: &TcpStream) -> RawFd {
socket.as_raw_fd()
}
```
Is optimized to the following:
```asm
example::as_raw_fd:
push rax
call qword ptr [rip + <std::net::tcp::TcpStream as std::sys_common::AsInner<std::sys_common::net::TcpStream>>::as_inner@GOTPCREL]
mov rdi, rax
call qword ptr [rip + std::sys_common::net::TcpStream::socket@GOTPCREL]
mov rdi, rax
pop rax
jmp qword ptr [rip + _ZN73_$LT$std..sys..unix..net..Socket$u20$as$u20$std..os..fd..raw..AsRawFd$GT$9as_raw_fd17h633bcf7e481df8bbE@GOTPCREL]
```
I think it would make more sense to inline trivial functions used within `TcpStream::AsRawFd`.
Explicitly document how Send and Sync relate to references Some of these relations were already mentioned in the text, but that Send is implemented for &mut impl Send was not mentioned, neither did the docs list when &T is Sync. Inspired by the discussion in #110961. [Proof](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ed77bfc3c77ba664400ebc2734f500e6) based on `@lukas-code` 's [example](rust-lang/rust#110961 (comment)).
Add slice::{split_,}{first,last}_chunk{,_mut}
This adds to the existing tracking issue for `slice::array_chunks` (#74985) under a separate feature, `slice_get_chunk`.
Currently, we have the existing `first`/`last` API for slices:
```rust
impl [T] {
pub const fn first(&self) -> Option<&T>;
pub const fn first_mut(&mut self) -> Option<&mut T>;
pub const fn last(&self) -> Option<&T>;
pub const fn last_mut(&mut self) -> Option<&mut T>;
pub const fn split_first(&self) -> Option<(&T, &[T])>;
pub const fn split_first_mut(&mut self) -> Option<(&mut T, &mut [T])>;
pub const fn split_last(&self) -> Option<(&T, &[T])>;
pub const fn split_last_mut(&mut self) -> Option<(&mut T, &mut [T])>;
}
```
This augments it with a `first_chunk`/`last_chunk` API that allows retrieving multiple elements at once:
```rust
impl [T] {
pub const fn first_chunk<const N: usize>(&self) -> Option<&[T; N]>;
pub const fn first_chunk_mut<const N: usize>(&mut self) -> Option<&mut [T; N]>;
pub const fn last_chunk<const N: usize>(&self) -> Option<&[T; N]>;
pub const fn last_chunk_mut<const N: usize>(&mut self) -> Option<&mut [T; N]>;
pub const fn split_first_chunk<const N: usize>(&self) -> Option<(&[T; N], &[T])>;
pub const fn split_first_chunk_mut<const N: usize>(&mut self) -> Option<(&mut [T; N], &mut [T])>;
pub const fn split_last_chunk<const N: usize>(&self) -> Option<(&[T; N], &[T])>;
pub const fn split_last_chunk_mut<const N: usize>(&mut self) -> Option<(&mut [T; N], &mut [T])>;
}
```
The code is based off of a copy of the existing API, with the documentation and examples properly modified. Currently, the most common way to perform these kinds of lookups with the existing methods is via `slice.as_chunks::<N>().0[0]` or the worse `slice.as_chunks::<N>().0[slice.len() - N]`, which is substantially less readable than `slice.first_chunk::<N>()` or `slice.last_chunk::<N>()`.
ACP: rust-lang/libs-team#69
Support #[global_allocator] without the allocator shim This makes it possible to use liballoc/libstd in combination with `--emit obj` if you use `#[global_allocator]`. This is what rust-for-linux uses right now and systemd may use in the future. Currently they have to depend on the exact implementation of the allocator shim to create one themself as `--emit obj` doesn't create an allocator shim. Note that currently the allocator shim also defines the oom error handler, which is normally required too. Once `#![feature(default_alloc_error_handler)]` becomes the only option, this can be avoided. In addition when using only fallible allocator methods and either `--cfg no_global_oom_handling` for liballoc (like rust-for-linux) or `--gc-sections` no references to the oom error handler will exist. To avoid this feature being insta-stable, you will have to define `__rust_no_alloc_shim_is_unstable` to avoid linker errors. (Labeling this with both T-compiler and T-lang as it originally involved both an implementation detail and had an insta-stable user facing change. As noted above, the `__rust_no_alloc_shim_is_unstable` symbol requirement should prevent unintended dependence on this unstable feature.)
Add Median of Medians fallback to introselect Fixes #102451. This PR is a follow up to #106997. It adds a Fast Deterministic Selection implementation as a fallback to the introselect algorithm used by `select_nth_unstable`. This allows it to guarantee O(n) worst case running time, while maintaining good performance in all cases. This would fix #102451, which was opened because the `select_nth_unstable` docs falsely claimed that it had O(n) worst case performance, even though it was actually quadratic in the worst case. #106997 improved the worst case complexity to O(n log n) by using heapsort as a fallback, and this PR further improves it to O(n) (this would also make #106933 unnecessary). It also improves the actual runtime if the fallback gets called: Using a pathological input of size `1 << 19` (see the playground link in #102451), calculating the median is roughly 3x faster using fast deterministic selection as a fallback than it is using heapsort. The downside to this is less code reuse between the sorting and selection algorithms, but I don't think it's that bad. The additional algorithms are ~250 LOC with no `unsafe` blocks (I tried using unsafe to avoid bounds checks but it didn't noticeably improve the performance). I also let it fuzz for a while against the current `select_nth_unstable` implementation to ensure correctness, and it seems to still fulfill all the necessary postconditions. cc `@scottmcm` who reviewed #106997
Clarify safety concern of `io::Read::read` is only relevant in unsafe code We have this clarification note in other similar place like [Iterator::size_hint](https://doc.rust-lang.org/stable/std/iter/trait.Iterator.html#method.size_hint). The lack of clarification might lead to confusion to Rust beginners. [Relevant URLO post](https://users.rust-lang.org/t/can-read-overflow-a-buffer/94347).
…lnay Remove structural match from `TypeId` As per rust-lang/rust#99189 (comment). > Removing the structural equality might make sense, but is a breaking change that'd require a libs-api FCP. rust-lang/rust#99189 (comment) > Landing this PR now (well, mainly the "remove structural equality" part) would unblock `const fn` `TypeId::of`, since we only postponed that because we were guaranteeing too much. See also #99189, #101698
Update current implementation comments for `select_nth_unstable` This more accurately reflects the actual implementation, as it hasn't been a simple quickselect since #106997. While it does say that the current implementation always runs in O(n), I don't think it should require an FCP as it doesn't guarantee linearity in general and only points out that the current implementation is in fact linear. r? `@Amanieu`
…lbertlarsan68,oli-obk new tool `rustdoc-gui-test` Implements new tool `rustdoc-gui-test` that allows using compiletest headers for `rustdoc-gui` tests.
[RFC-2011] Expand more expressions
cc #44838
Expands `if`, `let`, `match` and also makes `generic_assert_internals` an allowed feature when using `assert!`. `#![feature(generic_assert)]` is still needed to activate everything.
```rust
#![feature(generic_assert)]
fn fun(a: Option<i32>, b: Option<i32>, c: Option<i32>) {
assert!(
if a.is_some() { 1 } else { 2 } == 3
&& if let Some(elem) = b { elem == 4 } else { false }
&& match c { Some(_) => true, None => false }
);
}
fn main() {
fun(Some(1), None, Some(2));
}
// Assertion failed: assert!(
// if a.is_some() { 1 } else { 2 } == 3
// && if let Some(elem) = b { elem == 4 } else { false }
// && match c { Some(_) => true, None => false }
// );
//
// With captures:
// a = Some(1)
// b = None
// c = Some(2)
```
Stabilize `BuildHasher::hash_one` FCP completed in rust-lang/rust#86161 (comment)
Add #[inline] to array TryFrom impls I was looking into rust-lang/rust#111959 and I realized we don't have these. They seem like an uncontroversial addition. IMO this PR does not fix that issue. I think the bad codegen is being caused by some underlying deeper problem but this change might cause the MIR inliner to paper over it in this specific case. r? `@thomcc`
Rollup of 6 pull requests Successful merges: - #111936 (Include test suite metadata in the build metrics) - #111952 (Remove DesugaringKind::Replace.) - #111966 (Add #[inline] to array TryFrom impls) - #111983 (Perform MIR type ops locally in new solver) - #111997 (Fix re-export of doc hidden macro not showing up) - #112014 (rustdoc: get unnormalized link destination for suggestions) r? `@ghost` `@rustbot` modify labels: rollup
Rework handling of recursive panics
This PR makes 2 changes to how recursive panics works (a panic while handling a panic).
1. The panic count is no longer used to determine whether to force an immediate abort. This allows code like the following to work without aborting the process immediately:
```rust
struct Double;
impl Drop for Double {
fn drop(&mut self) {
// 2 panics are active at once, but this is fine since it is caught.
std::panic::catch_unwind(|| panic!("twice"));
}
}
let _d = Double;
panic!("once");
```
Rustc already generates appropriate code so that any exceptions escaping out of a `Drop` called in the unwind path will immediately abort the process.
2. Any panics while the panic hook is executing will force an immediate abort. This is necessary to avoid potential deadlocks like #110771 where a panic happens while holding the backtrace lock. We don't even try to print the panic message in this case since the panic may have been caused by `Display` impls.
Fixes #110771
Fix docs for `alloc::realloc` Fixes #108546. Corrects the docs for `alloc::realloc` to bring the safety constraints into line with `Layout::from_size_align_unchecked`'s constraints.
…Amanieu Use an unbounded lifetime in `String::leak`. Using `'a` instead of `'static` is predicted to make the process of making `String` generic over an allocator easier/less of a breaking change. See: - rust-lang/rust#109814 (comment) - rust-lang/rust#109814 (comment) ACP: rust-lang/libs-team#109
This prevents #113238 from hitting stable while we sort out options for avoiding it. The downgrade is expected to not affect any users on stable, since it primarily affects tier 3 targets.
|
Seems good. Closing since we certainly don't want to merge the 1.71 branch into 1.70, but the branch will live on. |
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.
Did this while postgres was building. Don't merge, it's in the right branch, this is just a CI check.