| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Revert to using `RtlGenRandom` as a fallback
This is required due to `BCryptGenRandom` failing to load a dll it depends on.
Fixes #108059
|
|
Rollup of 9 pull requests
Successful merges:
- #107573 (Update the minimum external LLVM to 14)
- #107626 (Fix `x fix` on the standard library itself)
- #107673 (update ICU4X to 1.1.0)
- #107733 (Store metrics from `metrics.json` to CI PGO timer)
- #108007 (Use `is_str` instead of string kind comparison)
- #108033 (add an unstable `#[rustc_coinductive]` attribute)
- #108039 (Refactor refcounted structural_impls via functors)
- #108040 (Use derive attributes for uninteresting traversals)
- #108044 (interpret: rename Pointer::from_addr → from_addr_invalid)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This is required due to `BCryptGenRandom` failing to load the necessary dll on some systems.
|
|
add an unstable `#[rustc_coinductive]` attribute
useful to test coinduction, especially in the new solver.
as this attribute should remain permanently unstable I don't think this needs any official approval. cc ``@rust-lang/types``
had to weaken the check for stable query results in the solver to prevent an ICE if there's a coinductive cycle with constraints.
r? ``@compiler-errors``
|
|
Update the minimum external LLVM to 14
With this change, we'll have stable support for LLVM 14 through 16 (pending release).
For reference, the previous increase to LLVM 13 was #100460.
|
|
Shrink size of array benchmarks
Might've overdone it with the size of these benchmarks, as there's no need for them to be quite as large.
Fixes #108011
|
|
"Basic usage" is redundant for there is just one example
|
|
|
|
|
|
|
|
Added another error to be processed in fallback
This pull request addresses the problem of Rust not being able to read file/directory metadata because the current user doesn't have permission to read the file and are thus inaccessible.
One particular example is `System Volume Information`. But any example can be made by having a file/directory, which the current user can't access even though the system does allow to view the metadata, which is handled by the fallback.
The fallback exists to get the metadata but it was limited to one error type. Having added ERROR_ACCESS_DENIED per Chris Denton's suggestion, file/directory properties are now properly read.
Solution suggested by Chris Denton https://github.com/nushell/nushell/issues/6857#issuecomment-1426847135
|
|
|
|
Added another error to be processed in fallback
Solution suggested by Chris Denton https://github.com/nushell/nushell/issues/6857#issuecomment-1426847135
|
|
Improve the `array::map` codegen
The `map` method on arrays [is documented as sometimes performing poorly](https://doc.rust-lang.org/std/primitive.array.html#note-on-performance-and-stack-usage), and after [a question on URLO](https://users.rust-lang.org/t/try-trait-residual-o-trait-and-try-collect-into-array/88510?u=scottmcm) prompted me to take another look at the core [`try_collect_into_array`](https://github.com/rust-lang/rust/blob/7c46fb2111936ad21a8e3aa41e9128752357f5d8/library/core/src/array/mod.rs#L865-L912) function, I had some ideas that ended up working better than I'd expected.
There's three main ideas in here, split over three commits:
1. Don't use `array::IntoIter` when we can avoid it, since that seems to not get SRoA'd, meaning that every step writes things like loop counters into the stack unnecessarily
2. Don't return arrays in `Result`s unnecessarily, as that doesn't seem to optimize away even with `unwrap_unchecked` (perhaps because it needs to get moved into a new LLVM type to account for the discriminant)
3. Don't distract LLVM with all the `Option` dances when we know for sure we have enough items (like in `map` and `zip`). This one's a larger commit as to do it I ended up adding a new `pub(crate)` trait, but hopefully those changes are still straight-forward.
(No libs-api changes; everything should be completely implementation-detail-internal.)
It's still not completely fixed -- I think it needs pcwalton's `memcpy` optimizations still (#103830) to get further -- but this seems to go much better than before. And the remaining `memcpy`s are just `transmute`-equivalent (`[T; N] -> ManuallyDrop<[T; N]>` and `[MaybeUninit<T>; N] -> [T; N]`), so hopefully those will be easier to remove with LLVM16 than the previous subobject copies 🤞
r? `@thomcc`
As a simple example, this test
```rust
pub fn long_integer_map(x: [u32; 64]) -> [u32; 64] {
x.map(|x| 13 * x + 7)
}
```
On nightly <https://rust.godbolt.org/z/xK7548TGj> takes `sub rsp, 808`
```llvm
start:
%array.i.i.i.i = alloca [64 x i32], align 4
%_3.sroa.5.i.i.i = alloca [65 x i32], align 4
%_5.i = alloca %"core::iter::adapters::map::Map<core::array::iter::IntoIter<u32, 64>, [closure@/app/example.rs:2:11: 2:14]>", align 8
```
(and yes, that's a 6**5**-element array `alloca` despite 6**4**-element input and output)
But with this PR it's only `sub rsp, 520`
```llvm
start:
%array.i.i.i.i.i.i = alloca [64 x i32], align 4
%array1.i.i.i = alloca %"core::mem::manually_drop::ManuallyDrop<[u32; 64]>", align 4
```
Similarly, the loop it emits on nightly is scalar-only and horrifying
```nasm
.LBB0_1:
mov esi, 64
mov edi, 0
cmp rdx, 64
je .LBB0_3
lea rsi, [rdx + 1]
mov qword ptr [rsp + 784], rsi
mov r8d, dword ptr [rsp + 4*rdx + 528]
mov edi, 1
lea edx, [r8 + 2*r8]
lea r8d, [r8 + 4*rdx]
add r8d, 7
.LBB0_3:
test edi, edi
je .LBB0_11
mov dword ptr [rsp + 4*rcx + 272], r8d
cmp rsi, 64
jne .LBB0_6
xor r8d, r8d
mov edx, 64
test r8d, r8d
jne .LBB0_8
jmp .LBB0_11
.LBB0_6:
lea rdx, [rsi + 1]
mov qword ptr [rsp + 784], rdx
mov edi, dword ptr [rsp + 4*rsi + 528]
mov r8d, 1
lea esi, [rdi + 2*rdi]
lea edi, [rdi + 4*rsi]
add edi, 7
test r8d, r8d
je .LBB0_11
.LBB0_8:
mov dword ptr [rsp + 4*rcx + 276], edi
add rcx, 2
cmp rcx, 64
jne .LBB0_1
```
whereas with this PR it's unrolled and vectorized
```nasm
vpmulld ymm1, ymm0, ymmword ptr [rsp + 64]
vpaddd ymm1, ymm1, ymm2
vmovdqu ymmword ptr [rsp + 328], ymm1
vpmulld ymm1, ymm0, ymmword ptr [rsp + 96]
vpaddd ymm1, ymm1, ymm2
vmovdqu ymmword ptr [rsp + 360], ymm1
```
(though sadly still stack-to-stack)
|
|
Rollup of 7 pull requests
Successful merges:
- #107654 (reword descriptions of the deprecated int modules)
- #107915 (Add `array::map` benchmarks)
- #107961 (Avoid copy-pasting the `ilog` panic string in a bunch of places)
- #107962 (Add a doc note about why `Chain` is not `ExactSizeIterator`)
- #107966 (Update browser-ui-test version to 0.14.3)
- #107970 (Hermit: Remove floor symbol)
- #107973 (Fix unintentional UB in SIMD tests)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Hermit: Remove floor symbol
This symbol should be provided by Hermit.
It was introduced in 2019 (https://github.com/rust-lang/rust/pull/65167). Since 2020, Hermit provides these math functions on its own (https://github.com/hermitcore/rusty-hermit/pull/37). I think moving this to Hermit was merely an oversight.
Related:
* https://github.com/hermitcore/libhermit-rs/pull/654
* https://github.com/hermitcore/rusty-hermit/pull/406
CC: `@stlankes`
|
|
Add a doc note about why `Chain` is not `ExactSizeIterator`
Inspired by <https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Why.20isn't.20Chain.3CA.2C.20B.3E.20an.20ExactSizeIterator.3F/near/327395874>.
|
|
Avoid copy-pasting the `ilog` panic string in a bunch of places
I also ended up changing the implementations to `if let` because it doesn't work to
```rust
self.checked_ilog2().unwrap_or_else(panic_for_nonpositive_argument)
```
due to the `!`. But as a bonus that meant I could remove the `rustc_allow_const_fn_unstable` too.
|
|
Add `array::map` benchmarks
Since there were no previous benchmarks for `array::map`, and it is known to have mediocre/poor performance, add some simple benchmarks. These benchmarks vary the length of the array and size of each item.
|
|
reword descriptions of the deprecated int modules
Based on recommendation by `@est31` here: https://github.com/rust-lang/rust/pull/107587#issuecomment-1416131590
This is meant to make it more clear, when looking at the `std` or `core` docs, that these are deprecated modules - not deprecated integer types (a common misunderstanding).
Before:
After:
|
|
Reverse Timsort scan direction
Another PR in the series of stable sort improvements. Best reviewed by looking at the individual commits.
The main perf gain here is for fully ascending (sorted) or reversed inputs for cheap to compare types such as `u64`, these see a ~1.5x speedup.
Types such as string with indirect pre-fetching see only minor changes. Further speedups are planned in future PRs so, I wouldn't spend too much time for benchmarks here.
|
|
This symbol should be provided by Hermit.
|
|
avoid mixing accesses of ptrs derived from a mutable ref and parent ptrs
``@Vanille-N`` is working on a successor for Stacked Borrows. It will mostly accept strictly more code than Stacked Borrows did, with one exception: the following pattern no longer works.
```rust
let mut root = 6u8;
let mref = &mut root;
let ptr = mref as *mut u8;
*ptr = 0; // Write
assert_eq!(root, 0); // Parent Read
*ptr = 0; // Attempted Write
```
This worked in Stacked Borrows kind of by accident: when doing the "parent read", under SB we Disable `mref`, but the raw ptrs derived from it remain usable. The fact that we can still use the "children" of a reference that is no longer usable is quite nasty and leads to some undesirable effects (in particular it is the major blocker for resolving https://github.com/rust-lang/unsafe-code-guidelines/issues/257). So in Tree Borrows we no longer do that; instead, reading from `root` makes `mref` and all its children read-only.
Due to other improvements in Tree Borrows, the entire Miri test suite still passes with this new behavior, and even the entire libcore and liballoc test suite, except for these 2 cases this PR fixes. Both of these involve code where the programmer wrote `&mut` but then used pointers derived from that reference in ways that alias with the parent pointer, which arguably is violating uniqueness. They are fixed by properly using raw pointers throughout.
|
|
Document `PointerLike`
I forgot to document this, and even though it's currently more of an implementation detail, the old doc was kinda embarrassing :sweat_smile:
|
|
|
|
|
|
Use associated items of `char` instead of freestanding items in `core::char`
The associated functions and constants on `char` have been stable since 1.52 and the freestanding items have soft-deprecated since 1.62 (https://github.com/rust-lang/rust/pull/95566). This PR ~~marks them as "deprecated in future", similar to the integer and floating point modules (`core::{i32, f32}` etc)~~ replaces all uses of `core::char::*` with `char::*` to prepare for future deprecation of `core::char::*`.
|
|
Speedup heapsort by 1.5x by making it branchless
`slice::sort_unstable` will fall back to heapsort if it repeatedly fails to find a good pivot. By making the core child update code branchless it is much faster. On Zen3 sorting 10k `u64` and forcing the sort to pick heapsort, results in:
455us -> 278us
|
|
|
|
Remove a couple of `#[doc(hidden)] pub fn` and their `#[feature]` gates
|
|
simplify layout calculations in rawvec
The use of `Layout::array` was introduced in #83706 which lead to a [perf regression](https://github.com/rust-lang/rust/pull/83706#issuecomment-1048377719).
This PR basically reverts that change since rust currently only supports stride == size types, but to be on the safe side it leaves a const-assert there to make sure this gets caught if those assumptions ever change.
|
|
This allows even better code-gen, cmp + adc. While also more clearly
communicating the intent.
|
|
Zero the `REPARSE_MOUNTPOINT_DATA_BUFFER` header
Makes sure the full header is correctly initialized.
Fixes #107884
|
|
Clarify `new_size` for realloc means bytes
Minor docs fix requested by https://github.com/rust-lang/rust/issues/107875
|
|
Stop at the first `NULL` argument when iterating `argv`
Some C commandline parsers (e.g. GLib and Qt) are replacing already handled arguments in `argv` with `NULL` and move them to the end. That means that `argc` might be bigger than the actual number of non-`NULL` pointers in `argv` at this point.
To handle this we simply stop iterating at the first `NULL` argument.
`argv` is also guaranteed to be `NULL`-terminated so any non-`NULL` arguments after the first `NULL` can safely be ignored.
Fixes https://github.com/rust-lang/rust/issues/105999
|
|
|
|
|
|
|
|
constant
|
|
Makes sure the full header is correctly initialized, including reserve parameters.
|
|
`slice::sort_unstable` will fall back to heapsort if it repeatedly fails to find
a good pivot. By making the core child update code branchless it is much faster.
On Zen3 sorting 10k `u64` and forcing the sort to pick heapsort, results in:
455us -> 278us
|
|
|
|
|
|
Use `__wasilibc_get_environ()` to read the environment variable list
from wasi-libc instead of using `environ`. `environ` is a global
variable which effectively requires wasi-libc to initialize the
environment variables eagerly, and `__wasilibc_get_environ()` is
specifically designed to be an alternative that lets wasi-libc
intiailize its environment variables lazily.
This should have the side effect of fixing at least some of the cases
of #107635.
|
|
rustdoc: use the same URL escape rules for fragments as for examples
Carries over improvements from #107284
|
|
r=dtolnay
Stabilize feature `cstr_from_bytes_until_nul`
This PR seeks to stabilize `cstr_from_bytes_until_nul`.
Partially addresses #95027
This function has only been on nightly for about 10 months, but I think it is simple enough that there isn't harm discussing stabilization. It has also had at least a handful of mentions on both the user forum and the discord, so it seems like it's already in use or at least known.
This needs FCP still.
Comment on potential discussion points:
- eventual conversion of `CStr` to be a single thin pointer: this function will still be useful to provide a safe way to create a `CStr` after this change.
- should this return a length too, to address concerns about the `CStr` change? I don't see it as being particularly useful, and it seems less ergonomic (i.e. returning `Result<(&CStr, usize), FromBytesUntilNulError>`). I think users that also need this length without the additional `strlen` call are likely better off using a combination of other methods, but this is up for discussion
- `CString::from_vec_until_nul`: this is also useful, but it doesn't even have a nightly implementation merged yet. I propose feature gating that separately, as opposed to blocking this `CStr` implementation on that
Possible alternatives:
A user can use `from_bytes_with_nul` on a slice up to `my_slice[..my_slice.iter().find(|c| c == 0).unwrap()]`. However; that is significantly less ergonomic, and is a bit more work for the compiler to optimize compared the direct `memchr` call that this wraps.
## New stable API
```rs
// both in core::ffi
pub struct FromBytesUntilNulError(());
impl CStr {
pub const fn from_bytes_until_nul(
bytes: &[u8]
) -> Result<&CStr, FromBytesUntilNulError>
}
```
cc ```@ericseppanen``` original author, ```@Mark-Simulacrum``` original reviewer, ```@m-ou-se``` brought up some issues on the thin pointer CStr
```@rustbot``` modify labels: +T-libs-api +needs-fcp
|
|
Implement `AsFd` and `AsRawFd` for `Rc`
Fixes https://github.com/rust-lang/rust/issues/105931.
|
|
Add missing tracking issue for `RawOsError`
I forgot to add it in the original PR…
See #107792.
```@rustbot``` label +T-libs-api -T-libs
|
|
Implement cursors for BTreeMap
See the ACP for an overview of the API: https://github.com/rust-lang/libs-team/issues/141
The implementation is split into 2 commits:
- The first changes the internal insertion functions to return a handle to the newly inserted element. The lifetimes involved are a bit hairy since we need a mutable handle to both the `BTreeMap` itself (which holds the root) and the nodes allocated in memory. I have tested that this passes the standard library testsuite under miri.
- The second commit implements the cursor API itself. This is more straightforward to follow but still involves some unsafe code to deal with simultaneous mutable borrows of the tree root and the node that is currently being iterated.
|
