| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Improve code example for length comparison
Small fix/improvement: it's much safer to check that you're under the length of an array rather than chacking that you're equal to it. It's even more true in case you update the length of the array while iterating.
|
|
|
|
|
|
|
|
This should do roughly the same as the TrustedLen specialization
but result in less IR by using __iterator_get_unchecked
instead of iterator.for_each.
|
|
Add strong_count mutation methods to Rc
The corresponding methods were stabilized on `Arc` in #79285 (tracking: #71983). This patch implements and stabilizes identical methods on the `Rc` types as well.
|
|
Bump bootstrap to 1.52 beta
This includes the standard bump, but also a workaround for new cargo behavior around clearing out the doc directory when the rustdoc version changes.
|
|
|
|
BTree: move blocks around in node.rs
Without changing any names or implementation, reorder some members:
- Move down the ones defined long ago on the demised `struct Root`, to below the definition of their current host `struct NodeRef`.
- Move up some defined on `struct NodeRef` that are interspersed with those defined on `struct Handle`.
- Move up the `correct_…` methods squeezed between the two flavours of `push`.
- Move the unchecked static downcasts (`cast_to_…`) after the upcasts (`forget_`) and the (weirdly named) dynamic downcasts (`force`).
r? ````@Mark-Simulacrum````
|
|
r=Mark-Simulacrum
BTree: no longer search arrays twice to check Ord
A possible addition to / partial replacement of #83147: no longer linearly search the upper bound of a range in the initial portion of the keys we already know are below the lower bound.
- Should be faster: fewer key comparisons at the cost of some instructions dealing with offsets
- Makes code a little more complicated.
- No longer detects ill-defined `Ord` implementations, but that wasn't a publicised feature, and was quite incomplete, and was only done in the `range` and `range_mut` methods.
r? `@Mark-Simulacrum`
|
|
Fix double-drop in `Vec::from_iter(vec.into_iter())` specialization when items drop during panic
This fixes the double-drop but it leaves a behavioral difference compared to the default implementation intact: In the default implementation the source and the destination vec are separate objects, so they get dropped separately. Here they share an allocation and the latter only exists as a pointer into the former. So if dropping the former panics then this fix will leak more items than the default implementation would. Is this acceptable or should the specialization also mimic the default implementation's drops-during-panic behavior?
Fixes #83618
`@rustbot` label T-libs-impl
|
|
|
|
Reduce the impact of Vec::reserve calls that do not cause any allocation
I think a lot of callers expect `Vec::reserve` to be nearly free when no resizing is required, but unfortunately that isn't the case. LLVM makes remarkably poor inlining choices (along the path from `Vec::reserve` to `RawVec::grow_amortized`), so depending on the surrounding context you either get a huge blob of `RawVec`'s resizing logic inlined into some seemingly-unrelated function, or not enough inlining happens and/or the actual check in `needs_to_grow` ends up behind a function call. My goal is to make the codegen for `Vec::reserve` match the mental that callers seem to have: It's reliably just a `sub cmp ja` if there is already sufficient capacity.
This patch has the following impact on the serde_json benchmarks: https://github.com/serde-rs/json-benchmark/tree/ca3efde8a5b75ff59271539b67452911860248c7 run with `cargo +stage1 run --release -- -n 1024`
Before:
```
DOM STRUCT
======= serde_json ======= parse|stringify ===== parse|stringify ====
data/canada.json 340 MB/s 490 MB/s 630 MB/s 370 MB/s
data/citm_catalog.json 460 MB/s 540 MB/s 1010 MB/s 550 MB/s
data/twitter.json 330 MB/s 840 MB/s 640 MB/s 630 MB/s
======= json-rust ======== parse|stringify ===== parse|stringify ====
data/canada.json 580 MB/s 990 MB/s
data/citm_catalog.json 720 MB/s 660 MB/s
data/twitter.json 570 MB/s 960 MB/s
```
After:
```
DOM STRUCT
======= serde_json ======= parse|stringify ===== parse|stringify ====
data/canada.json 330 MB/s 510 MB/s 610 MB/s 380 MB/s
data/citm_catalog.json 450 MB/s 640 MB/s 970 MB/s 830 MB/s
data/twitter.json 330 MB/s 880 MB/s 670 MB/s 960 MB/s
======= json-rust ======== parse|stringify ===== parse|stringify ====
data/canada.json 560 MB/s 1130 MB/s
data/citm_catalog.json 710 MB/s 880 MB/s
data/twitter.json 530 MB/s 1230 MB/s
```
That's approximately a one-third increase in throughput on two of the benchmarks, and no effect on one (The benchmark suite has sufficient jitter that I could pick a run where there are no regressions, so I'm not convinced they're meaningful here).
This also produces perf increases on the order of 3-5% in a few other microbenchmarks that I'm tracking. It might be useful to see if this has a cascading effect on inlining choices in some large codebases.
Compiling this simple program demonstrates the change in codegen that causes the perf impact:
```rust
fn main() {
reserve(&mut Vec::new());
}
#[inline(never)]
fn reserve(v: &mut Vec<u8>) {
v.reserve(1234);
}
```
Before:
```rust
00000000000069b0 <scratch::reserve>:
69b0: 53 push %rbx
69b1: 48 83 ec 30 sub $0x30,%rsp
69b5: 48 8b 47 08 mov 0x8(%rdi),%rax
69b9: 48 8b 4f 10 mov 0x10(%rdi),%rcx
69bd: 48 89 c2 mov %rax,%rdx
69c0: 48 29 ca sub %rcx,%rdx
69c3: 48 81 fa d1 04 00 00 cmp $0x4d1,%rdx
69ca: 77 73 ja 6a3f <scratch::reserve+0x8f>
69cc: 48 81 c1 d2 04 00 00 add $0x4d2,%rcx
69d3: 72 75 jb 6a4a <scratch::reserve+0x9a>
69d5: 48 89 fb mov %rdi,%rbx
69d8: 48 8d 14 00 lea (%rax,%rax,1),%rdx
69dc: 48 39 ca cmp %rcx,%rdx
69df: 48 0f 47 ca cmova %rdx,%rcx
69e3: 48 83 f9 08 cmp $0x8,%rcx
69e7: be 08 00 00 00 mov $0x8,%esi
69ec: 48 0f 47 f1 cmova %rcx,%rsi
69f0: 48 85 c0 test %rax,%rax
69f3: 74 17 je 6a0c <scratch::reserve+0x5c>
69f5: 48 8b 0b mov (%rbx),%rcx
69f8: 48 89 0c 24 mov %rcx,(%rsp)
69fc: 48 89 44 24 08 mov %rax,0x8(%rsp)
6a01: 48 c7 44 24 10 01 00 movq $0x1,0x10(%rsp)
6a08: 00 00
6a0a: eb 08 jmp 6a14 <scratch::reserve+0x64>
6a0c: 48 c7 04 24 00 00 00 movq $0x0,(%rsp)
6a13: 00
6a14: 48 8d 7c 24 18 lea 0x18(%rsp),%rdi
6a19: 48 89 e1 mov %rsp,%rcx
6a1c: ba 01 00 00 00 mov $0x1,%edx
6a21: e8 9a fe ff ff call 68c0 <alloc::raw_vec::finish_grow>
6a26: 48 8b 7c 24 20 mov 0x20(%rsp),%rdi
6a2b: 48 8b 74 24 28 mov 0x28(%rsp),%rsi
6a30: 48 83 7c 24 18 01 cmpq $0x1,0x18(%rsp)
6a36: 74 0d je 6a45 <scratch::reserve+0x95>
6a38: 48 89 3b mov %rdi,(%rbx)
6a3b: 48 89 73 08 mov %rsi,0x8(%rbx)
6a3f: 48 83 c4 30 add $0x30,%rsp
6a43: 5b pop %rbx
6a44: c3 ret
6a45: 48 85 f6 test %rsi,%rsi
6a48: 75 08 jne 6a52 <scratch::reserve+0xa2>
6a4a: ff 15 38 c4 03 00 call *0x3c438(%rip) # 42e88 <_GLOBAL_OFFSET_TABLE_+0x490>
6a50: 0f 0b ud2
6a52: ff 15 f0 c4 03 00 call *0x3c4f0(%rip) # 42f48 <_GLOBAL_OFFSET_TABLE_+0x550>
6a58: 0f 0b ud2
6a5a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
```
After:
```asm
0000000000006910 <scratch::reserve>:
6910: 48 8b 47 08 mov 0x8(%rdi),%rax
6914: 48 8b 77 10 mov 0x10(%rdi),%rsi
6918: 48 29 f0 sub %rsi,%rax
691b: 48 3d d1 04 00 00 cmp $0x4d1,%rax
6921: 77 05 ja 6928 <scratch::reserve+0x18>
6923: e9 e8 fe ff ff jmp 6810 <alloc::raw_vec::RawVec<T,A>::reserve::do_reserve_and_handle>
6928: c3 ret
6929: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
```
|
|
alloc: Added `as_slice` method to `BinaryHeap` collection
I initially asked about whether it is useful addition on https://internals.rust-lang.org/t/should-i-add-as-slice-method-to-binaryheap/13816, and it seems there were no objections, so went ahead with this PR.
> There is [`BinaryHeap::into_vec`](https://doc.rust-lang.org/std/collections/struct.BinaryHeap.html#method.into_vec), but it consumes the value. I wonder if there is API design limitation that should be taken into account. Implementation-wise, the inner buffer is just a Vec, so it is trivial to expose as_slice from it.
Please, guide me through if I need to add tests or something else.
UPD: Tracking issue #83659
|
|
|
|
|
|
may not -> might not
may not -> might not
"may not" has two possible meanings:
1. A command: "You may not stay up past your bedtime."
2. A fact that's only sometimes true: "Some cities may not have bike lanes."
In some cases, the meaning is ambiguous: "Some cars may not have snow
tires." (do the cars *happen* to not have snow tires, or is it
physically impossible for them to have snow tires?)
This changes places where the standard library uses the "description of
fact" meaning to say "might not" instead.
This is just `std::vec` for now - if you think this is a good idea I can
convert the rest of the standard library.
|
|
Adjust documentation links for slice::make_ascii_*case
The documentation for the functions `slice::to_ascii_lowercase` and `slice::to_ascii_uppercase` contain the suggestion
> To lowercase the value in-place, use `make_ascii_lowercase`
however the link to the suggested method takes you to the page for `u8`, rather than the method of that name on the same page.
|
|
Fixes API soundness issue in join()
Fixes #80335
|
|
"may not" has two possible meanings:
1. A command: "You may not stay up past your bedtime."
2. A fact that's only sometimes true: "Some cities may not have bike lanes."
In some cases, the meaning is ambiguous: "Some cars may not have snow
tires." (do the cars *happen* to not have snow tires, or is it
physically impossible for them to have snow tires?)
This changes places where the standard library uses the "description of
fact" meaning to say "might not" instead.
This is just `std::vec` for now - if you think this is a good idea I can
convert the rest of the standard library.
|
|
Add function core::iter::zip
This makes it a little easier to `zip` iterators:
```rust
for (x, y) in zip(xs, ys) {}
// vs.
for (x, y) in xs.into_iter().zip(ys) {}
```
You can `zip(&mut xs, &ys)` for the conventional `iter_mut()` and
`iter()`, respectively. This can also support arbitrary nesting, where
it's easier to see the item layout than with arbitrary `zip` chains:
```rust
for ((x, y), z) in zip(zip(xs, ys), zs) {}
for (x, (y, z)) in zip(xs, zip(ys, zs)) {}
// vs.
for ((x, y), z) in xs.into_iter().zip(ys).zip(xz) {}
for (x, (y, z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {}
```
It may also format more nicely, especially when the first iterator is a
longer chain of methods -- for example:
```rust
iter::zip(
trait_ref.substs.types().skip(1),
impl_trait_ref.substs.types().skip(1),
)
// vs.
trait_ref
.substs
.types()
.skip(1)
.zip(impl_trait_ref.substs.types().skip(1))
```
This replaces the tuple-pair `IntoIterator` in #78204.
There is prior art for the utility of this in [`itertools::zip`].
[`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html
|
|
rustdoc link format
|
|
same type, rather than on u8
|
|
Add IEEE 754 compliant fmt/parse of -0, infinity, NaN
This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values, namely signed zero, the infinities, and NaN. It also adds IEEE 754 compliance tests that, while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests, are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks.
This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074, and closes #24623.
The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers, i.e. not the extended reals (where floats live), IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely, when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition, the vast majority of other programming languages not only output `-0` but output `-0.0` here.
While IEEE 754 offers a broad leeway in how to handle producing what it calls a "decimal character sequence", it is clear that the operations a language provides should be capable of round tripping, and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further, existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character, but it prints "+0" instead if given such (which was what led to the opening of #24623).
There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard, as well as other well-documented challenges on the arithmetic level, but I hope that this can be the beginning of motion towards solving those challenges.
|
|
Make # pretty print format easier to discover
# Rationale:
I use (cargo cult?) three formats in rust: `{}`, debug `{:?}`, and pretty-print debug `{:#?}`. I discovered `{:#?}` in some blog post or guide when I started working in Rust. While `#` is documented I think it is hard to discover. So taking the good advice of ```@carols10cents``` I am trying to improve the docs with a PR
As a reminder "pretty print" means that where `{:?}` will print something like
```
foo: { b1: 1, b2: 2}
```
`{:#?}` will prints something like
```
foo {
b1: 1
b2: 3
}
```
# Changes
Add an example to `fmt` to try and make it easier to discover `#`
|
|
|
|
Add docs for Vec::from functions
Part of #51430
|
|
|
|
|
|
Part of #51430
|
|
|
|
|
|
This seems to have been omitted from the beginning when this feature
was first introduced in 86bf96291d82.
Most users won't need to name this type which is probably why this
wasn't noticed in the meantime.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
"semantic equivalence" is too strong a phrasing here, which is why
actually explaining what kind of circumstances might produce a -0
was chosen instead.
|
|
|
|
Stabilize or_patterns (RFC 2535, 2530, 2175)
closes #54883
This PR stabilizes the or_patterns feature in Rust 1.53.
This is blocked on the following (in order):
- [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021
- [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705)
- It looks like we will need to pursue some sort of edition-based transition for `:pat`.
- [x] Nomination and discussion by T-lang
- [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100).
- [ ] An FCP on stabilization
EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #80193 (stabilize `feature(osstring_ascii)`)
- #80771 (Make NonNull::as_ref (and friends) return refs with unbound lifetimes)
- #81607 (Implement TrustedLen and TrustedRandomAccess for Range<integer>, array::IntoIter, VecDequeue's iterators)
- #82554 (Fix invalid slice access in String::retain)
- #82686 (Move `std::sys::unix::platform` to `std::sys::unix::ext`)
- #82771 (slice: Stabilize IterMut::as_slice.)
- #83329 (Cleanup LLVM debuginfo module docs)
- #83336 (Fix ICE with `use clippy::a::b;`)
- #83350 (Download a more recent LLVM version if `src/version` is modified)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix invalid slice access in String::retain
As noted in #78499, the previous fix was technically still unsound because it accessed elements of a slice outside its bounds (even though they were still inside the same allocation). This PR addresses that concern by switching to a dropguard approach.
|
|
|
|
|
|
This allows the optimizer to turn certain iterator pipelines such as
```rust
let vec = vec![0usize; 100];
vec.into_iter().map(|e| e as isize).collect::<Vec<_>>()
```
into a noop.
The optimization only applies when iterator sources are `T: Copy`
since `impl TrustedRandomAccess for IntoIter<T>`.
No such requirement applies to the output type (`Iterator::Item`).
|
|
|
|
|
|
Fix const stability `since` versions.
fixes #82085
r? `@m-ou-se`
|
|
|
|
|
|
Fix overflowing length in Vec<ZST> to VecDeque
`Vec` can hold up to `usize::MAX` ZST items, but `VecDeque` has a lower
limit to keep its raw capacity as a power of two, so we should check
that in `From<Vec<T>> for VecDeque<T>`. We can also simplify the
capacity check for the remaining non-ZST case.
Before this fix, the new test would fail on the length:
```
thread 'collections::vec_deque::tests::test_from_vec_zst_overflow' panicked at 'assertion failed: `(left == right)`
left: `0`,
right: `9223372036854775808`', library/alloc/src/collections/vec_deque/tests.rs:474:5
note: panic did not contain expected string
panic message: `"assertion failed: `(left == right)`\n left: `0`,\n right: `9223372036854775808`"`,
expected substring: `"capacity overflow"`
```
That was a result of `len()` using a mask `& (size - 1)` with the
improper length. Now we do get a "capacity overflow" panic as soon as
that `VecDeque::from(vec)` is attempted.
Fixes #80167.
|
|
Implement String::remove_matches
Closes #50206.
I lifted the function help from `@frewsxcv's` original PR (#50015), hope they don't mind.
I'm also wondering whether it would be useful for `remove_matches` to collect up the removed substrings into a `Vec` and return them, right now they're just overwritten by the copy and lost.
|
|
|
