| Age | Commit message (Collapse) | Author | Lines |
|---|
|
2229: Mark insignificant dtor in stdlib
I looked at all public [stdlib Drop implementations](https://doc.rust-lang.org/stable/std/ops/trait.Drop.html#implementors) and categorized them into Insigificant/Maybe/Significant Drop.
Reasons are noted here: https://docs.google.com/spreadsheets/d/19edb9r5lo2UqMrCOVjV0fwcSdS-R7qvKNL76q7tO8VA/edit#gid=1838773501
One thing missing from this PR is tagging HashMap as insigificant destructor as that needs some discussion.
r? `@Mark-Simulacrum`
cc `@nikomatsakis`
|
|
Signed-off-by: Xuanwo <github@xuanwo.io>
|
|
Signed-off-by: Xuanwo <github@xuanwo.io>
|
|
Stabilize Vec<T>::shrink_to
This PR stabilizes `shrink_to` feature and closes the corresponding issue. The second point was addressed already, and no `panic!` should occur.
Closes #56431.
|
|
|
|
Hide allocator details from TryReserveError
I think there's [no need for TryReserveError to carry detailed information](https://github.com/rust-lang/rust/issues/48043#issuecomment-825139280), but I wouldn't want that issue to delay stabilization of the `try_reserve` feature.
So I'm proposing to stabilize `try_reserve` with a `TryReserveError` as an opaque structure, and if needed, expose error details later.
This PR moves the `enum` to an unstable inner `TryReserveErrorKind` that lives under a separate feature flag. `TryReserveErrorKind` could possibly be left as an implementation detail forever, and the `TryReserveError` get methods such as `allocation_size() -> Option<usize>` or `layout() -> Option<Layout>` instead, or the details could be dropped completely to make try-reserve errors just a unit struct, and thus smaller and cheaper.
|
|
The sentence exists to highlight the existence of a
performance footgun of repeated calls of the
reserve_exact function.
|
|
Update the examples in `String` and `VecDeque::retain`
The examples added in #60396 used a "clever" post-increment hack,
unrelated to the actual point of the examples. That hack was found
[confusing] in the users forum, and #81811 already changed the `Vec`
example to use a more direct iterator. This commit changes `String` and
`VecDeque` in the same way for consistency.
[confusing]: https://users.rust-lang.org/t/help-understand-strange-expression/62858
|
|
The examples added in #60396 used a "clever" post-increment hack,
unrelated to the actual point of the examples. That hack was found
[confusing] in the users forum, and #81811 already changed the `Vec`
example to use a more direct iterator. This commit changes `String` and
`VecDeque` in the same way for consistency.
[confusing]: https://users.rust-lang.org/t/help-understand-strange-expression/62858
|
|
|
|
guarantees about subtype coercions
Update all the TrustedRandomAccess impls to also implement the new supertrait
|
|
Add support for custom allocator in `VecDeque`
This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections.
`@rustbot` modify labels: +A-allocators +T-libs
|
|
Stabilize `impl From<[(K, V); N]> for HashMap` (and friends)
In addition to allowing HashMap to participate in Into/From conversion, this adds the long-requested ability to use constructor-like syntax for initializing a HashMap:
```rust
let map = HashMap::from([
(1, 2),
(3, 4),
(5, 6)
]);
```
This addition is highly motivated by existing precedence, e.g. it is already possible to similarly construct a Vec from a fixed-size array:
```rust
let vec = Vec::from([1, 2, 3]);
```
...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa):
```rust
let vec = Vec::from([(1, 2)]);
let map: HashMap<_, _> = vec.into_iter().collect();
let vec: Vec<(_, _)> = map.into_iter().collect();
```
...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)):
```rust
let arr = [(1, 2)];
let map: HashMap<_, _> = std::array::IntoIter::new(arr).collect();
```
Therefore this addition seems like a no-brainer.
As for any impl, this would be insta-stable.
|
|
|
|
|
|
|
|
|
|
|
|
Removes the implementations that depend on the user-definable trait `Copy`.
Only fix regressions to ensure merge in 1.55: Does not modify `vec::IntoIter`.
|
|
|
|
|
|
|
|
This method on the Iterator trait is doc(hidden), and about half of
implementations were doc(hidden). This adds the attribute to the
remaining implementations.
|
|
Update standard library for IntoIterator implementation of arrays
This PR partially resolves issue #84513 of updating the standard library part.
I haven't found any remaining doctest examples which are using iterators over e.g. &i32 instead of just i32 in the standard library. Can anyone point me to them if there's remaining any?
Thanks!
r? ```@m-ou-se```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Since just `ops::Try` will need to change meaning.
|
|
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
|
|
|
|
#78021
|
|
|
|
|
|
`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 #80303.
|
|
Remove unreachable panics from VecDeque::{front/back}[_mut]
`VecDeque`'s `front`, `front_mut`, `back` and `back_mut` methods are implemented in terms of the index operator, which causes these functions to contain [unreachable panic calls](https://rust.godbolt.org/z/MTnq1o).
This PR reimplements these methods in terms of `get[_mut]` instead.
|
|
|
|
Taken from #80293.
|
|
Fix stabilization version of deque_range feature.
See https://github.com/rust-lang/rust/pull/79022#issuecomment-751315315
|
|
|
|
|
|
stabilize deque_range
Make #74217 stable, stabilizing `VecDeque::range` and `VecDeque::range_mut`.
Pr: #74099
r? `@m-ou-se`
|
|
|
