Commit Graph

1154 Commits

Author SHA1 Message Date
bors
ad981d58e1 Auto merge of #86879 - YohDeadfall:stabilize-vec-shrink-to, r=dtolnay
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.
2021-08-08 19:37:02 +00:00
David Tolnay
8ec5060cdd
Bump shrink_to stabilization to Rust 1.56 2021-08-08 11:36:53 -07:00
bors
996ff2e0a0 Auto merge of #87408 - kornelski:try_reserve_error, r=yaahc
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.
2021-08-07 01:26:15 +00:00
bors
4c29cc8fd0 Auto merge of #87777 - the8472:fix-mir-max-rss, r=oli-obk,joshtriplett
Use zeroed allocations in the mir interpreter instead eagerly touching the memory

#86255 introduced a 30% regression in [page faults](https://perf.rust-lang.org/compare.html?start=64ae15ddd3f3cca7036ab2b2f3a6b130b62af4da&end=39e20f1ae5f13451eb35247808d6a2527cb7d060&stat=faults
) and a 3% regression in [max-rss](https://perf.rust-lang.org/index.html?start=2021-07-01&end=&absolute=false&stat=max-rss) in the ctfe-stress benchmarks.
That's most likely happened because it separated allocation from initialization of the vec which defeats the zero-optimization.

Currently there's no allocation API that is fallible, zeroing and returns a slice, so this PR introduces one and then uses that to solve the problem. In principle `vec.resize(len, 0)` could be optimized to use `alloc::grow_zeroed` where appropriate but that would require new specializations and new plumbing in `RawVec`.
2021-08-06 12:11:30 +00:00
The8472
1c21373b50 add Box::try_new_uninit_slice for symmetry 2021-08-05 21:21:52 +02:00
The8472
6ed2d870fc remove cfg gate on use RawVec since it is now also used in fallible code 2021-08-05 19:45:02 +02:00
est31
1db8737f65 alloc: Use intra doc links for the reserve function
The sentence exists to highlight the existence of a
performance footgun of repeated calls of the
reserve_exact function.
2021-08-05 04:23:54 +02:00
The8472
de91157389 add Box::try_new_zeroed_slice()
Currently there is no API that allows fallible zero-allocation of a Vec.
Vec.try_reserve is not appropriate for this job since it doesn't know
whether it should zero or arbitrary uninitialized memory is fine.

Since Box currently holds most of the zeroing/uninit/slice allocation APIs
it's the best place to add yet another entry into this feature matrix.
2021-08-05 00:23:19 +02:00
bors
b53a93db2d Auto merge of #87535 - lf-:authors, r=Mark-Simulacrum
rfc3052 followup: Remove authors field from Cargo manifests

Since RFC 3052 soft deprecated the authors field, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information for contributors, we may as well
remove it from crates in this repo.
2021-08-02 05:49:17 +00:00
Yuki Okushi
0c9b35b8c7
Rollup merge of #87644 - Flying-Toast:vec-remove-note, r=the8472
Recommend `swap_remove` in `Vec::remove` docs

I was able to increase the performance (by 20%!) of my project by changing a `Vec::remove` call to `Vec::swap_remove` in a hot function. I think we should explicitly put a note in the Vec::remove docs to guide people in the right direction so they don't make a similar oversight.
2021-08-02 11:03:30 +09:00
bors
cd5a90fb14 Auto merge of #86031 - ssomers:btree_lazy_iterator, r=Mark-Simulacrum
BTree: lazily locate leaves in rangeless iterators

BTree iterators always locate both the first and last leaf edge and often only need either one, i.e., whenever they are traversed in a single direction, like in for-loops and in the common use of `iter().next()` or `iter().next_back()` to retrieve the first or last key/value-pair (#62924). It's fairly easy to avoid because the iterators with this disadvantage already are quite separate from other iterators.

r? `@Mark-Simulacrum`
2021-08-01 21:45:30 +00:00
bors
f381e77d35 Auto merge of #84662 - dtolnay:unwindsafe, r=Amanieu
Move UnwindSafe, RefUnwindSafe, AssertUnwindSafe to core

They were previously only available in std::panic, not core::panic.

- https://doc.rust-lang.org/1.51.0/std/panic/trait.UnwindSafe.html
- https://doc.rust-lang.org/1.51.0/std/panic/trait.RefUnwindSafe.html
- https://doc.rust-lang.org/1.51.0/std/panic/struct.AssertUnwindSafe.html

Where this is relevant: trait objects! Inside a `#![no_std]` library it's otherwise impossible to have a struct holding a trait object, and at the same time can be used from downstream std crates in a way that doesn't interfere with catch_unwind.

```rust
// common library

#![no_std]

pub struct Thing {
    pub(crate) x: &'static (dyn SomeTrait + Send + Sync),
}

pub(crate) trait SomeTrait {...}
```

```rust
// downstream application

fn main() {
    let thing: library::Thing = ...;
    let _ = std::panic::catch_unwind(|| { let _ = thing; });  // does not work :(
}
```

See a4131708e2/src/gradient.rs (L7-L15) for a real life example of needing to work around this problem. In particular that workaround would not even be viable if implementors of the trait were provided externally by a caller, as the `feature = "std"` would become non-additive in that case.

What happens without the UnwindSafe constraints:

```rust
fn main() {
    let gradient = colorous::VIRIDIS;
    let _ = std::panic::catch_unwind(|| { let _ = gradient; });
}
```

```console
error[E0277]: the type `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary
   --> src/main.rs:3:13
    |
3   |     let _ = std::panic::catch_unwind(|| { let _ = gradient; });
    |             ^^^^^^^^^^^^^^^^^^^^^^^^ `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary
    |
   ::: .rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:430:40
    |
430 | pub fn catch_unwind<F: FnOnce() -> R + UnwindSafe, R>(f: F) -> Result<R> {
    |                                        ---------- required by this bound in `catch_unwind`
    |
    = help: within `Gradient`, the trait `RefUnwindSafe` is not implemented for `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)`
    = note: required because it appears within the type `&'static (dyn colorous::gradient::EvalGradient + Send + Sync + 'static)`
    = note: required because it appears within the type `Gradient`
    = note: required because of the requirements on the impl of `UnwindSafe` for `&Gradient`
    = note: required because it appears within the type `[closure@src/main.rs:3:38: 3:62]`
```
2021-08-01 02:53:13 +00:00
David Tolnay
96ecaa17a7
Relocate Arc and Rc UnwindSafe impls 2021-07-31 03:57:49 -07:00
bors
b289bb7fdf Auto merge of #87488 - kornelski:track-remove, r=dtolnay
Track caller of Vec::remove()

`vec.remove(invalid)` doesn't print a helpful source position:

> thread 'main' panicked at 'removal index (is 99) should be < len (is 1)', **library/alloc/src/vec/mod.rs:1379:13**
2021-07-31 03:00:20 +00:00
Flying-Toast
9a2e3f3a8e Recommend swap_remove in Vec::remove docs 2021-07-30 16:01:49 -04:00
David Tolnay
701e3a45a9
Fix comment referring to formerly-above code 2021-07-30 10:42:19 -07:00
David Tolnay
4e17994b2c
Move UnwindSafe, RefUnwindSafe, AssertUnwindSafe to core 2021-07-30 10:42:15 -07:00
Yuki Okushi
3bc6c28376
Rollup merge of #87574 - cuviper:retain-examples, r=joshtriplett
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
2021-07-30 16:26:57 +09:00
Jade
3cf820e17d rfc3052: Remove authors field from Cargo manifests
Since RFC 3052 soft deprecated the authors field anyway, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information, we should remove it from
crates in this repo.
2021-07-29 14:56:05 -07:00
Ali Malik
e43254aad1 Fix may not to appropriate might not or must not 2021-07-29 01:15:20 -04:00
bors
85237886df Auto merge of #85874 - steffahn:fix_unsound_zip_optimization, r=yaahc
Remove unsound TrustedRandomAccess implementations

Removes the implementations that depend on the user-definable trait `Copy`.

Fixes #85873 in the most straightforward way.

<hr>

_Edit:_ This PR now contains additional trait infrastructure to avoid performance regressions around in-place collect, see the discussion in this thread starting from the codegen test failure at https://github.com/rust-lang/rust/pull/85874#issuecomment-872327577.

With this PR, `TrustedRandomAccess` gains additional documentation that specifically allows for and specifies the safety conditions around subtype coercions – those coercions can happen in safe Rust code with the `Zip` API’s usage of `TrustedRandomAccess`. This PR introduces a new supertrait of `TrustedRandomAccess`(currently named `TrustedRandomAccessNoCoerce`) that _doesn’t allow_ such coercions, which means it can be still be useful for optimizing cases such as in-place collect where no iterator is handed out to a user (who could do coercions) after a `get_unchecked` call; the benefit of the supertrait is that it doesn’t come with the additional safety conditions around supertraits either, so it can be implemented for more types than `TrustedRandomAccess`.

The `TrustedRandomAccess` implementations for `vec::IntoIter`, `vec_deque::IntoIter`, and `array::IntoIter` are removed as they don’t conform with the newly documented safety conditions, this way unsoundness is removed. But this PR in turn (re-)adds a `TrustedRandomAccessNoCoerce` implementation for `vec::IntoIter` to avoid performance regressions from stable in a case of in-place collecting of `Vec`s [the above-mentioned codegen test failure]. Re-introducing the (currently nightly+beta-only) impls for `VecDeque`’s and `[T; N]`’s iterators is technically possible, but goes beyond the scope of this PR (i.e. it can happen in a future PR).
2021-07-29 00:31:07 +00:00
Josh Stone
d4a60ab34f 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
2021-07-28 16:35:59 -07:00
Frank Steffahn
6d9c0a16d9 Documentation improvements 2021-07-28 14:33:37 +02:00
Frank Steffahn
89583e98e8 Make SpecInPlaceCollect use TrustedRandomAccessNoCoerce 2021-07-28 14:33:36 +02:00
Frank Steffahn
9ff421da99 Remove redundant bounds on get_unchecked for vec_deque iterators, and run fmt 2021-07-28 14:33:36 +02:00
Frank Steffahn
f9c982c8fd Add back TrustedRandomAccess-specialization for Vec, but only without coercions 2021-07-28 14:33:36 +02:00
Frank Steffahn
69dd992f95 Add TrustedRandomAccessNoCoerce supertrait without requirements or guarantees about subtype coercions
Update all the TrustedRandomAccess impls to also implement the new supertrait
2021-07-28 14:33:35 +02:00
Frank Steffahn
a0d8a324eb Remove unsound TrustedRandomAccess implementations
Removes the implementations that depend on the user-definable trait `Copy`.
2021-07-28 14:33:28 +02:00
Yuki Okushi
23479f716a
Rollup merge of #87501 - spastorino:remove-min-tait, r=oli-obk
Remove min_type_alias_impl_trait in favor of type_alias_impl_trait

r? ``@oli-obk``
2021-07-28 18:28:19 +09:00
Santiago Pastorino
5bff8429a0
Use type_alias_impl_trait instead of min in compiler and lib 2021-07-27 12:27:08 -03:00
bors
99d6692f6c Auto merge of #87431 - the8472:array-iter-fold, r=kennytm
implement fold() on array::IntoIter to improve flatten().collect() perf

With #87168 flattening `array::IntoIter`s is now `TrustedLen`, the `FromIterator` implementation for `Vec` has a specialization for `TrustedLen` iterators which uses internal iteration. This implements one of the main internal iteration methods on `array::Into` to optimize the combination of those two features.

This should address the main issue in #87411

```
# old
test vec::bench_flat_map_collect                         ... bench:   2,244,024 ns/iter (+/- 18,903)

# new
test vec::bench_flat_map_collect                         ... bench:     172,863 ns/iter (+/- 2,141)
```
2021-07-27 10:38:41 +00:00
bors
998cfe5aad Auto merge of #85305 - MarcusDunn:master, r=pnkfelix
Stabilize bindings_after_at

attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490), im pretty new to the whole thing so any pointers are greatly appreciated.
2021-07-27 05:53:31 +00:00
bors
c51607e031 Auto merge of #87062 - poliorcetics:fix-85462, r=dtolnay
Make StrSearcher behave correctly on empty needle

Fix #85462.

This will not affect ABI since the other variant of the enum is bigger.
It may break some code, but that would be very strange: usually people
don't continue after the first `Done` (or `None` for a normal iterator).

`@rustbot` label T-libs A-str A-patterns
2021-07-27 00:31:20 +00:00
Kornel
624df182ea Track caller of Vec::remove() 2021-07-26 18:39:59 +01:00
bors
9c25eb7aa3 Auto merge of #86595 - a1phyr:allocator_api_for_vecdeque, r=Amanieu
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
2021-07-25 19:01:10 +00:00
bors
2b4196e977 Auto merge of #84111 - bstrie:hashfrom, r=joshtriplett
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.
2021-07-24 22:31:14 +00:00
Kornel
a294aa8d3d Hide allocator details from TryReserveError 2021-07-24 22:25:08 +01:00
bstrie
1b83fedda4 Update std_collections_from_array stability version 2021-07-24 14:04:51 -04:00
The8472
e015e9da71 implement fold() on array::IntoIter to improve flatten().collect() perf
```
# old
test vec::bench_flat_map_collect                         ... bench:   2,244,024 ns/iter (+/- 18,903)

# new
test vec::bench_flat_map_collect                         ... bench:     172,863 ns/iter (+/- 2,141)
```
2021-07-24 19:24:11 +02:00
Yuki Okushi
1a2b90bc91
Rollup merge of #87255 - RalfJung:miri-test-libcore, r=Mark-Simulacrum
better support for running libcore tests with Miri

See https://github.com/rust-lang/miri-test-libstd/issues/4 for a description of the problem that this fixes.
Thanks to `@hyd-dev` for suggesting this patch!
2021-07-24 04:31:07 +09:00
Yuki Okushi
249a11f936
Rollup merge of #86790 - janikrabe:retain-iter-order-doc, r=m-ou-se
Document iteration order of `retain` functions

For `HashSet` and `HashMap`, this simply copies the comment from
`BinaryHeap::retain`.

For `BTreeSet` and `BTreeMap`, this adds an additional guarantee that
wasn't previously documented. I think that because these data structures
are inherently ordered and other functions guarantee ordered iteration,
it makes sense to provide this guarantee for `retain` as well.
2021-07-24 04:30:56 +09:00
Benoît du Garreau
19318e625b Add #[unstable] on new functions 2021-07-23 20:37:12 +02:00
Benoît du Garreau
6fcc62b3ac Add unstable attribute for A in Drain and IntoIter 2021-07-23 20:37:12 +02:00
Benoît du Garreau
0570f09a33 Add support for custom allocator in VecDeque 2021-07-23 20:37:09 +02:00
Frank Steffahn
1b66a799c7 Remove unsound TrustedRandomAccess implementations
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`.
2021-07-21 14:37:23 +02:00
Ralf Jung
6cba79851a better support for running libcore and liballoc tests with Miri 2021-07-18 19:11:45 +02:00
Yuki Okushi
07faa2e32c
Rollup merge of #87170 - xFrednet:clippy-5393-add-diagnostic-items, r=Manishearth,oli-obk
Add diagnostic items for Clippy

This adds a bunch of diagnostic items to `std`/`core`/`alloc` functions, structs and traits used in Clippy. The actual refactorings in Clippy to use these items will be done in a different PR in Clippy after the next sync.

This PR doesn't include all paths Clippy uses, I've only gone through the first 85 lines of Clippy's [`paths.rs`](ecf85f4bdc/clippy_utils/src/paths.rs) (after rust-lang/rust-clippy#7466) to get some feedback early on. I've also decided against adding diagnostic items to methods, as it would be nicer and more scalable to access them in a nicer fashion, like adding a `is_diagnostic_assoc_item(did, sym::Iterator, sym::map)` function or something similar (Suggested by `@camsteffen` [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/Diagnostic.20Item.20Naming.20Convention.3F/near/225024603))

There seems to be some different naming conventions when it comes to diagnostic items, some use UpperCamelCase (`BinaryHeap`) and some snake_case (`hashmap_type`). This PR uses UpperCamelCase for structs and traits and snake_case with the module name as a prefix for functions. Any feedback on is this welcome.

cc: rust-lang/rust-clippy#5393

r? `@Manishearth`
2021-07-18 14:21:57 +09:00
xFrednet
d38f2b0cc1 Added diagnostic items to structs and traits for Clippy 2021-07-15 23:57:02 +02:00
Alex Gaynor
a214911b77 Added Arc::try_pin
This helper is in line with other other allocation helpers on Arc.
2021-07-15 07:32:05 -04:00
Stein Somers
10b65c821f Make BTreeSet::split_off name elements like other set methods do 2021-07-12 22:48:14 +02:00