Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#135602 (Tweak output of missing lifetime on associated type)
- rust-lang/rust#139751 (Implement pin-project in pattern matching for `&pin mut|const T`)
- rust-lang/rust#142682 (Update bundled musl to 1.2.5)
- rust-lang/rust#148171 (Simplify code to generate line numbers in highlight)
- rust-lang/rust#148263 (Unpin `libc` and `rustix` in `compiler` and `rustbook`)
- rust-lang/rust#148301 ([rustdoc search] Include extern crates when filtering on `import`)
- rust-lang/rust#148330 (Don't require dlltool with the dummy backend on MinGW)
- rust-lang/rust#148338 (cleanup: upstream dropped amx-transpose functionality)
- rust-lang/rust#148340 (Clippy subtree update)
- rust-lang/rust#148343 (`nonpoison::Condvar` should take `MutexGuard` by reference)
r? `@ghost`
`@rustbot` modify labels: rollup
`nonpoison::Condvar` should take `MutexGuard` by reference
Feature: `#![feature(nonpoison_condvar)]`
Tracking Issue: https://github.com/rust-lang/rust/issues/134645
Specific comment: https://github.com/rust-lang/rust/issues/134645#issuecomment-3458525913
Changes the `nonpoison::Condvar` API to take `MutexGuard` by reference instead of ownership.
I'm actually not entirely sure why the current poison variant of `Condvar` takes by ownership, is it just legacy reasons?
Additionally, the `nonpoison_and_poison_unwrap_test` macro doesn't really make sense anymore now that the APIs are completely different, so this reverts that change from a few months ago.
r? ````@Amanieu````
cleanup: upstream dropped amx-transpose functionality
See also LLVM change 5322fb626820. Looks like this was just removed entirely.
It seems a little bad to just drop it, but I don't see an easy way to conditionalize
this and if it's really just Gone and we marked it as unstable (which it looks like
we did?) I guess we should just dump it.
````@rustbot```` label llvm-main
Since non-poisoning `Condvar` take non-poisoing `Mutex`es when
`wait`ing, we do not need to take by ownership since a poison error
cannot occur while we wait.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Setup for writing different tests for the `nonpoison::Condvar` since it
will have a different API.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Enable file locking support in illumos
https://github.com/rust-lang/rust/pull/132977 introduced an allow-list of targets supporting file locking, but forgot to add illumos to it (which introduced support for it in ~2015). `File::lock` and friends are now stable, and the ecosystem is slowly replacing custom libc calls with the standard library. Crucially, in 1.91 both Cargo and bootstrap switched to `File::lock`, both breaking build directory locking.
This PR enables file locking on illumos. Fixes https://github.com/rust-lang/rust/issues/146312.
Use fstatat() in DirEntry::metadata on Apple platforms
Apple supports `fstatat` on macOS >=10.10 ([source](https://gitlab.gnome.org/GNOME/glib/-/issues/2203)), and according to [Platform Support](https://doc.rust-lang.org/beta/rustc/platform-support.html) the oldest supported version is 10.12.
Google says iOS >=10 supports `fstatat` but doesn't provide a source. [*-apple-ios](https://doc.rust-lang.org/beta/rustc/platform-support/apple-ios.html#os-version) says the minimum supported iOS version is 10.0.
Unsure about tvOS, watchOS and visionOS, hoping CI can confirm this.
I am testing with [fastdu](https://github.com/jesseschalken/fastdu) which is effectively a stress test for `DirEntry::metadata`. In one test this provides a **1.13x** speedup.
```
$ hyperfine --warmup 1 'target/release/fastdu testdir' 'fastdu testdir'
Benchmark 1: target/release/fastdu testdir
Time (mean ± σ): 154.6 ms ± 17.4 ms [User: 31.7 ms, System: 187.6 ms]
Range (min … max): 148.4 ms … 225.5 ms 19 runs
Benchmark 2: fastdu testdir
Time (mean ± σ): 175.3 ms ± 15.8 ms [User: 50.0 ms, System: 196.2 ms]
Range (min … max): 165.4 ms … 211.7 ms 17 runs
Summary
target/release/fastdu testdir ran
1.13 ± 0.16 times faster than fastdu testdir
```
You can also reproduce a speedup with a program like this (providing a directory with many entries):
```rust
fn main() {
let args: Vec<_> = std::env::args_os().collect();
let dir: PathBuf = args[1].clone().into();
for entry in dir.read_dir().as_mut().unwrap() {
let entry = entry.as_ref().unwrap();
let metadata = entry.metadata();
let metadata = metadata.as_ref().unwrap();
println!("{} {}", metadata.len(), entry.file_name().display());
}
}
```
```
$ hyperfine './target/release/main testdir' './main testdir'
Benchmark 1: ./target/release/main testdir
Time (mean ± σ): 148.3 ms ± 5.2 ms [User: 23.1 ms, System: 122.9 ms]
Range (min … max): 145.2 ms … 167.2 ms 19 runs
Benchmark 2: ./main testdir
Time (mean ± σ): 164.4 ms ± 9.5 ms [User: 32.6 ms, System: 128.8 ms]
Range (min … max): 158.5 ms … 199.5 ms 17 runs
Summary
./target/release/main testdir ran
1.11 ± 0.07 times faster than ./main testdir
```
`unicode_data` refactors
Minor refactors to `unicode_data` that occured to me while trying to reduce the size of the tables. Splitting into a separate PR. NFC
Instead of generating a standalone executable to test `unicode_data`,
generate normal tests in `coretests`. This ensures tests are always
generated, and will be run as part of the normal testsuite.
Also change the generated tests to loop over lookup tables, rather than
generating a separate `assert_eq!()` statement for every codepoint. The
old approach produced a massive (20,000 lines plus) file which took
minutes to compile!
To make the final output code easier to see:
* Get rid of the unnecessary line-noise of `.unwrap()`ing calls to
`write!()` by moving the `.unwrap()` into a macro.
* Join consecutive `write!()` calls using a single multiline format
string.
* Replace `.push()` and `.push_str(format!())` with `write!()`.
* If after doing all of the above, there is only a single `write!()`
call in the function, just construct the string directly with
`format!()`.
Remove `#[rustfmt::skip]` from all the generated modules in
`unicode_data.rs`. This means we won't have to worry so much about
getting indetation and formatting right when generating code.
Exempted for now some tables which would be too big when formatted by
`rustfmt`.
Instead of `include_str!()`ing `range_search.rs`, just make it a normal
module under `core::unicode`. This means the same source code doesn't
have to be checked in twice, and it plays nicer with IDEs.
Also rename it to `rt` since it includes functions for searching the
bitsets and case conversion tables as well as the range
represesentation.
Move wasm `throw` intrinsic back to `unwind`
Fixesrust-lang/rust#148246, less invasive than the previously proposed rust-lang/rust#148269. Removes the publicly visible unstable intrinsic tracked in rust-lang/rust#122465 since it's not clear how to export it in a sound manner.
r? `@bjorn3`
---
rustc assumes that regular `extern "Rust"` functions unwind only if the `unwind` panic runtime is linked. `throw` was annotated as such, but unwound unconditionally. This could cause UB when a crate built with `-C panic=abort` called `throw` from `core` built with `-C panic=unwind`, since no terminator was added to handle the panic arising from calling an allegedly non-unwinding `extern "Rust"` function.
rustc was taught to recognize this condition since https://github.com/rust-lang/rust/pull/144225 and prevented such linkage, but this caused regressions in
https://github.com/rust-lang/rust/issues/148246, since this meant that Emscripten projects could not be built with `-C panic=abort` without recompiling std.
The most straightforward solution would be to move `throw` into the `panic_unwind` crate, so that it's only compiled if the panic runtime is guaranteed to be `unwind`, but this is messy due to our architecture. Instead, move it into `unwind::wasm`, which is only compiled for bare-metal targets that default to `panic = "abort"`, rendering the issue moot.
rustc assumes that regular `extern "Rust"` functions unwind only if the
`unwind` panic runtime is linked. `throw` was annotated as such, but
unwound unconditionally. This could cause UB when a crate built with `-C
panic=abort` called `throw` from `core` built with `-C panic=unwind`,
since no terminator was added to handle the panic arising from calling an
allegedly non-unwinding `extern "Rust"` function.
rustc was taught to recognize this condition since
https://github.com/rust-lang/rust/pull/144225 and prevented such
linkage, but this caused regressions in
https://github.com/rust-lang/rust/issues/148246, since this meant that
Emscripten projects could not be built with `-C panic=abort` without
recompiling std.
The most straightforward solution would be to move `throw` into the
`panic_unwind` crate, so that it's only compiled if the panic runtime is
guaranteed to be `unwind`, but this is messy due to our architecture.
Instead, move it into `unwind::wasm`, which is only compiled for
bare-metal targets that default to `panic = "abort"`, rendering the
issue moot.
Turn `Cow::is_borrowed,is_owned` into associated functions.
This is done because `Cow` implements `Deref`. Therefore, to avoid conflicts with an inner type having a method of the same name, we use an associated method, like `Box::into_raw`.
Tracking issue: #65143
Improve the ICE message for invalid nullary intrinsic calls
In https://github.com/rust-lang/rust/issues/148104, we found the panic message here rather confusing, and (if I'm reading the tea leaves right) that's because the intended audience for either side of the phrase is very different. I think this is more clear if/when this is encountered by users.
I expect this ICE to be hit in practice by people calling the `size_of` and `align_of` intrinsics, so it's now _kind of_ helpful for those users too.
The original effort to stop backends from needing to support nullary intrinsics added a note to all these const-only intrinsics, but when https://github.com/rust-lang/rust/pull/147793 ported two more the paragraph wasn't added. I've added it.
Revert constification of `Borrow` and `Deref for Cow` due to inference failure
Reported issue: rust-lang/rust#147964
Original PR: rust-lang/rust#145279
Previous revert: rust-lang/rust#148011
`const Borrow`/`Deref` tracking issue: rust-lang/rust#143773
Should have additional crater run to verify this fixes the issue.
Since other PR is in the queue, this will need to be rebased after that merges. Also will want a beta nomination.
Document MaybeUninit bit validity
Partially addresses https://github.com/rust-lang/unsafe-code-guidelines/issues/555 by clarifying that it is sound to write any byte values (initialized or uninitialized) to any `MaybeUninit<T>` regardless of `T`.
r? `@RalfJung`
Revert constification of `AsRef for Cow` due to inference failure
Reported issue: rust-lang/rust#147964
Original PR: rust-lang/rust#145279
`const AsRef` tracking issue: rust-lang/rust#143773
Should have additional crater run to verify this fixes the issue.
Add `String::replace_first` and `String::replace_last`
Rebase of #97977 (cc `@WilliamVenner)`
> Convenience methods that use `match_indices` and `replace_range` to efficiently replace a substring in a string without reallocating, if capacity (and the implementation of `Vec::splice`) allows.
The intra-doc link to `str::replacen` is a direct url-based link to `str::replacen` in `std`'s docs to work around #98941. This means that when building only `alloc`'s docs (and not `std`'s), it will be a broken link. There is precedent for this e.g. in [`core::hint::spin_loop`](https://doc.rust-lang.org/nightly/src/core/hint.rs.html#214) which links to `std::thread::yield_now` using a [url-based link](https://github.com/rust-lang/rust/blob/master/library/core/src/hint.rs#L265) and thus is a dead link when only building `core`'s docs.
ACP: https://github.com/rust-lang/libs-team/issues/506
Matthias Krüger