| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add vec_deque::Iter::as_slices and friends
Add the following methods, that work similarly to VecDeque::as_slices:
- alloc::collections::vec_deque::Iter::as_slices
- alloc::collections::vec_deque::IterMut::into_slices
- alloc::collections::vec_deque::IterMut::as_slices
- alloc::collections::vec_deque::IterMut::as_mut_slices
Obtaining slices from a VecDeque iterator was not previously possible.
|
|
They are unusual methods. The docs don't really describe the cases when
they might be useful (as opposed to just `get`), and the examples don't
demonstrate the interesting cases at all.
This commit improves the docs and the examples.
|
|
The internal `btree::Recover` trait acted as a private API between
`BTreeSet` and `BTreeMap`, but we can use `pub(_)` restrictions these
days, and some of the methods don't need special handling anymore.
* `BTreeSet::get` can use `BTreeMap::get_key_value`
* `BTreeSet::take` can use `BTreeMap::remove_entry`
* `BTreeSet::replace` does need help, but this now uses a `pub(super)`
method on `BTreeMap` instead of the trait.
* `btree::Recover` is now removed.
|
|
|
|
These are all standard dictionary words and don't require hyphenation.
|
|
|
|
Add `#[track_caller]` to allocating methods of `Vec` & `VecDeque`
Part 4 in a lengthy saga.
r? `@joshtriplett` because they were the reviewer the last 3 times.
`@bors` rollup=never "[just in case this has perf effects, Vec is hot](https://github.com/rust-lang/rust/pull/79323#issuecomment-731866746)"
This was first attempted in #79323 by `@nvzqz.` It got approval from `@joshtriplett,` but rotted with merge conflicts and got closed.
Then it got picked up by `@Dylan-DPC-zz` in #83359. A benchmark was run[^perf], the results (after a bit of thinking[^thinking]) were deemed ok[^ok], but there was a typo[^typo] and the PR was made from a wrong remote in the first place[^remote], so #83909 was opened instead.
By the time #83909 rolled around, the methods in question had received some optimizations[^optimizations], so another perf run was conducted[^perf2]. The results were ok[^ok2]. There was a suggestion to add regression tests for panic behavior [^tests], but before it could be addressed, the PR fell victim to merge conflicts[^conflicts] and died again[^rip].
3 years have passed, and (from what I can tell) this has not been tried again, so here I am now, reviving this old effort.
Given how much time has passed and the fact that I've also touched `VecDeque` this time, it probably makes sense to
`@bors` try `@rust-timer`
[^perf]: https://github.com/rust-lang/rust/pull/83359#issuecomment-804450095
[^thinking]: https://github.com/rust-lang/rust/pull/83359#issuecomment-805286704
[^ok]: https://github.com/rust-lang/rust/pull/83359#issuecomment-812739031
[^typo]: https://github.com/rust-lang/rust/pull/83359#issuecomment-812750205
[^remote]: https://github.com/rust-lang/rust/pull/83359#issuecomment-814067119
[^optimizations]: https://github.com/rust-lang/rust/pull/83909#issuecomment-813736593
[^perf2]: https://github.com/rust-lang/rust/pull/83909#issuecomment-813825552
[^ok2]: https://github.com/rust-lang/rust/pull/83909#issuecomment-813831341
[^tests]: https://github.com/rust-lang/rust/pull/83909#issuecomment-825788964
[^conflicts]: https://github.com/rust-lang/rust/pull/83909#issuecomment-851173480
[^rip]: https://github.com/rust-lang/rust/pull/83909#issuecomment-873569771
|
|
|
|
Since the stabilization in #127679 has reached stage0, 1.82-beta, we can
start using `&raw` freely, and even the soft-deprecated `ptr::addr_of!`
and `ptr::addr_of_mut!` can stop allowing the unstable feature.
I intentionally did not change any documentation or tests, but the rest
of those macro uses are all now using `&raw const` or `&raw mut` in the
standard library.
|
|
|
|
Disallow hidden references to mutable static
Closes #123060
Tracking:
- https://github.com/rust-lang/rust/issues/123758
|
|
|
|
|
|
|
|
|
|
some const cleanup: remove unnecessary attributes, add const-hack indications
I learned that we use `FIXME(const-hack)` on top of the "const-hack" label. That seems much better since it marks the right place in the code and moves around with the code. So I went through the PRs with that label and added appropriate FIXMEs in the code. IMO this means we can then remove the label -- Cc ``@rust-lang/wg-const-eval.``
I also noticed some const stability attributes that don't do anything useful, and removed them.
r? ``@fee1-dead``
|
|
|
|
|
|
Bump boostrap compiler to new beta
Accidentally left some comments on the update cfgs commit directly xd
|
|
|
|
enable -Zrandomize-layout in debug CI builds
This builds rustc/libs/tools with `-Zrandomize-layout` on *-debug CI runners.
Only a handful of tests and asserts break with that enabled, which is promising. One test was fixable, the rest is dealt with by disabling them through new cargo features or compiletest directives.
The config.toml flag `rust.randomize-layout` defaults to false, so it has to be explicitly enabled for now.
|
|
|
|
struct sizes
|
|
|
|
|
|
impl `Default` for collection iterators that don't already have it
There is a pretty strong precedent for implementing `Default` for collection iterators, and this does so for some where this implementation was missed.
I don't think this needs a separate ACP (since this precedent already exists, and these feel like they were just missed), however, it *will* need an FCP since these implementations are instantly stable.
|
|
Implement cursors for `BTreeSet`
Tracking issue: https://github.com/rust-lang/rust/issues/107540
This is a straightforward wrapping of the map API, except that map's `CursorMut` does not make sense, because there is no value to mutate. Hence, map's `CursorMutKey` is wrapped here as just `CursorMut`, since it's unambiguous for sets and we don't normally speak of "keys". On the other hand, I can see some potential for confusion with `CursorMut` meaning different things in each module. I'm happy to take suggestions to improve that.
r? ````@Amanieu````
|
|
|
|
like map API
|
|
|
|
|
|
Add missing periods on `BTreeMap` cursor `peek_next` docs
Tracking issue: https://github.com/rust-lang/rust/issues/107540
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
|
|
|
|
|
|
|
|
Many tiny changes to stdlib doc comments to make them consistent (for example
"Returns foo", rather than "Return foo", per RFC1574), adding missing periods, paragraph
breaks, backticks for monospace style, and other minor nits.
https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md#appendix-a-full-conventions-text
|
|
Update tracking issue for `const_binary_heap_new_in`
This PR updates the tracking issue of `const_binary_heap_new_in` feature:
- Old issue: #112353
- New issue: #125961
|
|
Mark format! with must_use hint
Uses unstable feature https://github.com/rust-lang/rust/issues/94745
Part of #126475
First contribution to rust, please let me know if the blessing of tests is correct
Thanks `@bjorn3` for the help
|
|
Rollup of 8 pull requests
Successful merges:
- #127179 (Print `TypeId` as hex for debugging)
- #127189 (LinkedList's Cursor: method to get a ref to the cursor's list)
- #127236 (doc: update config file path in platform-support/wasm32-wasip1-threads.md)
- #127297 (Improve std::Path's Hash quality by avoiding prefix collisions)
- #127308 (Attribute cleanups)
- #127354 (Describe Sized requirements for mem::offset_of)
- #127409 (Emit a wrap expr span_bug only if context is not tainted)
- #127447 (once_lock: make test not take as long in Miri)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Don't check the capacity every time (and also for `Extend` for tuples, as this is how `unzip()` is implemented).
I did this with an unsafe method on `Extend` that doesn't check for growth (`extend_one_unchecked()`). I've marked it as perma-unstable currently, although we may want to expose it in the future so collections outside of std can benefit from it. Then specialize `Extend for (A, B)` for `TrustedLen` to call it.
It may seem that an alternative way of implementing this is to have a semi-public trait (`#[doc(hidden)]` public, so collections outside of core can implement it) for `extend()` inside tuples, and specialize it from collections. However, it is impossible due to limitations of `min_specialization`.
A concern that may arise with the current approach is that implementing `extend_one_unchecked()` correctly must also incur implementing `extend_reserve()`, otherwise you can have UB. This is a somewhat non-local safety invariant. However, I believe this is fine, since to have actual UB you must have unsafe code inside your `extend_one_unchecked()` that makes incorrect assumption, *and* not implement `extend_reserve()`. I've also documented this requirement.
|
|
|
|
|
|
This is possible now that inline const blocks are stable; the idea was
even mentioned as an alternative when `uninit_array()` was added:
<https://github.com/rust-lang/rust/pull/65580#issuecomment-544200681>
> if it’s stabilized soon enough maybe it’s not worth having a
> standard library method that will be replaceable with
> `let buffer = [MaybeUninit::<T>::uninit(); $N];`
Const array repetition and inline const blocks are now stable (in the
next release), so that circumstance has come to pass, and we no longer
have reason to want `uninit_array()` other than convenience. Therefore,
let’s evaluate the inconvenience by not using `uninit_array()` in
the standard library, before potentially deleting it entirely.
|
|
|
|
Stabilize `binary_heap_as_slice`
This PR stabilizes `binary_heap_as_slice`:
```rust
// std::collections::BinaryHeap
impl BinaryHeap<T> {
pub fn as_slice(&self) -> &[T]
}
```
<br>
Tracking issue: https://github.com/rust-lang/rust/issues/83659.
Implementation PR: https://github.com/rust-lang/rust/pull/82331.
FCPs already completed in the tracking issue.
Closes https://github.com/rust-lang/rust/issues/83659.
r? libs-api
|
|
|
|
|
|
`const_binary_heap_new_in` for `BinaryHeap::new_in`
|
