add a note to Vec's Extend<&T> impl about its slice specialization
From the regular documentation view, it's not at all apparent that [this specialization](5669c9988f/src/liballoc/vec.rs (L1879-L1891)) exists for `slice::Iter`. This adds a documentation blurb to the Extend impl itself to note that this optimization exists.
Make the "main" constructors of NonZero/Shared/Unique return Option
Per discussion in https://github.com/rust-lang/rust/issues/27730#issuecomment-303939441.
This is a breaking change to unstable APIs.
The old behavior is still available under the name `new_unchecked`. Note that only that one can be `const fn`, since `if` is currently not allowed in constant contexts.
In the case of `NonZero` this requires adding a new `is_zero` method to the `Zeroable` trait. I mildly dislike this, but it’s not much worse than having a `Zeroable` trait in the first place. `Zeroable` and `NonZero` are both unstable, this can be reworked later.
Clarify that sort_unstable is deterministic
@frankmcsherry complained that the documentation said "it is randomized but deterministic", which is a contradictory statement.
This PR uses a different and clearer wording.
Fix in weak_count in Arc in the case the weak count is locked.
In the case the weak count was locked, the weak_count function could
return usize::MAX. We need to test this condition manually.
This precondition takes the form of a behavorial change in
`Layout::from_size_align` (so it returns `None` if the `align` is too
large) and a new requirement for safe usage of
`Layout::from_size_align_unchecked`.
Fix#30170.
rustc: Implement the #[global_allocator] attribute
This PR is an implementation of [RFC 1974] which specifies a new method of
defining a global allocator for a program. This obsoletes the old
`#![allocator]` attribute and also removes support for it.
[RFC 1974]: https://github.com/rust-lang/rfcs/pull/1974
The new `#[global_allocator]` attribute solves many issues encountered with the
`#![allocator]` attribute such as composition and restrictions on the crate
graph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.
cc #27389
This PR is an implementation of [RFC 1974] which specifies a new method of
defining a global allocator for a program. This obsoletes the old
`#![allocator]` attribute and also removes support for it.
[RFC 1974]: https://github.com/rust-lang/rfcs/pull/197
The new `#[global_allocator]` attribute solves many issues encountered with the
`#![allocator]` attribute such as composition and restrictions on the crate
graph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.
cc #27389
Document unintuitive argument order for Vec::dedup_by relation
When trying to use `dedup_by` to merge some auxiliary information from removed elements into kept elements, I was surprised to observe that `vec.dedup_by(same_bucket)` calls `same_bucket(a, b)` where `b` appears before `a` in the vector, and discards `a` when true is returned. This argument order is probably a bug, but since it has already been stabilized, I guess we should document it as a feature and move on.
(`Vec::dedup` also uses `==` with this unexpected argument order, but I figure that’s not important since `==` is expected to be symmetric with no side effects.)
Delete deprecated & unstable range-specific `step_by`
Using the new one is annoying while this one exists, since the inherent method hides the one on iterator.
Tracking issue: #27741
Replacement: #41439
Deprecation: #42310 for 1.19
Fixes#41477
When trying to use dedup_by to merge some auxiliary information from
removed elements into kept elements, I was surprised to observe that
vec.dedup_by(same_bucket) calls same_bucket(a, b) where b appears
before a in the vector, and discards a when true is returned. This
argument order is probably a bug, but since it has already been
stabilized, I guess we should document it as a feature and move on.
(Vec::dedup also uses == with this unexpected argument order, but I
figure that’s not important since == is expected to be symmetric with
no side effects.)
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Improve tests and benchmarks for slice::sort and slice::sort_unstable
This PR just hardens the tests and improves benchmarks.
More specifically:
1. Benchmarks don't generate vectors in `Bencher::iter` loops, but simply clone pregenerated vectors.
2. Benchmark `*_strings` doesn't allocate Strings in `Bencher::iter` loops, but merely clones a `Vec<&str>`.
3. Benchmarks use seeded `XorShiftRng` to be more consistent.
4. Additional tests for `slice::sort` are added, which test sorting on slices with several ascending/descending runs. The implementation identifies such runs so it's a good idea to test that scenario a bit.
5. More checks are added to `run-pass/vector-sort-panic-safe.rs`. Sort algorithms copy elements around a lot (merge sort uses an auxilliary buffer and pdqsort copies the pivot onto the stack before partitioning, then writes it back into the slice). If elements that are being sorted are internally mutable and comparison function mutates them, it is important to make sure that sort algorithms always use the latest "versions" of elements. New checks verify that this is true for both `slice::sort` and `slice::sort_unstable`.
As a side note, all of those improvements were made as part of the parallel sorts PR in Rayon (nikomatsakis/rayon#379) and now I'm backporting them into libcore/libstd.
r? @alexcrichton
std: Fix implementation of `Alloc::alloc_one`
This had an accidental `u8 as *mut T` where it was intended to have just a
normal pointer-to-pointer cast.
Closes#42827
Relaxed Debug constraints on {HashMap,BTreeMap}::{Keys,Values}.
I has hit by this yesterday too. 😄
And I've realised that Debug for BTreeMap::{Keys,Values} wasn't formatting just keys and values respectively, but the whole map. 🤔Fixed#41924
r? @jonhoo
Replaced by adding extra imports, adding hidden code (`# ...`), modifying
examples to be runnable (sorry Homura), specifying non-Rust code, and
converting to should_panic, no_run, or compile_fail.
Remaining "```ignore"s received an explanation why they are being ignored.
