1
Fork 0
Commit graph

272 commits

Author SHA1 Message Date
Michael Howell
a402cb0f9b docs: use intra-doc links for Vec::get(_mut)
Now that #63351 is fixed, there's no reason not to.
2023-02-23 12:26:14 -07:00
Ben Kimock
738c8b08d5 Remove the assume(!is_null) from Vec::as_ptr 2023-02-19 14:30:21 -05:00
Neil Roberts
a34f11c006 vec: Use SpecCloneIntoVec::clone_into to implement Vec::clone_from
In the past, Vec::clone_from was implemented using slice::clone_into.
The code from clone_into was later duplicated into clone_from in
8725e4c337, which is the commit that adds custom allocator support to
Vec. Presumably this was done because the slice::clone_into only works
for vecs with the default allocator so it would have the wrong type to
clone into Vec<T, A>.

Now that the clone_into implementation is moved out into a specializable
trait anyway we might as well use that to share the code between the two
methods.
2023-01-28 20:37:01 +01:00
André Vennberg
0b35f448f8 Remove various double spaces in source comments. 2023-01-14 17:22:04 +01:00
Kevin Reid
288e89bf76 Document that Vec::from_raw_parts[_in] must be given a pointer from the correct allocator. 2023-01-07 15:56:36 -08:00
jonathanCogan
db47071df2 Replace libstd, libcore, liballoc in line comments. 2022-12-30 14:00:42 +01:00
Chayim Refael Friedman
4df5459dd1
Update the documentation of Vec to use extend(array) instead of extend(array.iter().copied()) 2022-12-27 19:44:58 +02:00
Fabian Hintringer
f9490c8121 improve doc 2022-11-28 22:42:05 +01:00
Scott McMurray
9d68a1a74c Tune RepeatWith::try_fold and Take::for_each and Vec::extend_trusted 2022-11-24 19:14:19 -08:00
Scott McMurray
a8954f1f6a Stop peeling the last iteration of the loop in Vec::repeat_with 2022-11-24 03:12:54 -08:00
Scott McMurray
1c966e7f15 Extract the logic for TrustedLen to a named method that can be called directly 2022-11-24 03:12:05 -08:00
ripytide
743726e352
Vec: IntoIterator signature consistency
Also makes the code dryer.
2022-11-06 15:25:00 +00:00
Douwe Schulte
f65cb6868d
Fixed typos
Fixed a typo that has been found on two locations in comments.
2022-11-03 21:19:02 +00:00
Nixon Enraght-Moony
674cd6125d Clairify Vec::capacity docs
Fixes #103326
2022-10-24 15:01:58 +01:00
Matthias Krüger
1b2f594f48
Rollup merge of #103359 - WaffleLapkin:drain_no_mut_qqq, r=scottmcm
Remove incorrect comment in `Vec::drain`

r? ``@scottmcm``

Turns out this comment wasn't correct for 6 years, since #34951, which switched from using `slice::IterMut` into using `slice::Iter`.
2022-10-22 00:14:03 +02:00
Maybe Waffle
e97d295d00 Remove incorrect comment in Vec::drain 2022-10-21 15:29:02 +00:00
Chris Denton
913393a0f7
Allow Vec::leak with no_global_oom_handling 2022-10-17 17:12:32 +01:00
bors
1a7c203e7f Auto merge of #89123 - the8472:push_in_capacity, r=amanieu
add Vec::push_within_capacity - fallible, does not allocate

This method can serve several purposes. It

* is fallible
* guarantees that items in Vec aren't moved
* allows loops that do `reserve` and `push` separately to avoid pulling in the allocation machinery a second time in the `push` part which should make things easier on the optimizer
* eases the path towards `ArrayVec` a bit since - compared to `push()` - there are fewer questions around how it should be implemented

I haven't named it `try_push` because that should probably occupy a middle ground that will still try to reserve and only return an error in the unlikely OOM case.

resolves #84649
2022-10-09 21:02:33 +00:00
Dylan DPC
f24d00d8b3
Rollup merge of #101642 - SkiFire13:fix-inplace-collection-leak, r=the8472
Fix in-place collection leak when remaining element destructor panic

Fixes #101628

cc `@the8472`

I went for the drop guard route, placing it immediately before the `forget_allocation_drop_remaining` call and after the comment, as to signal they are closely related.

I also updated the test to check for the leak, though the only change really needed was removing the leak clean up for miri since now that's no longer leaked.
2022-10-04 16:11:01 +05:30
Matthias Krüger
2110d2de5a
Rollup merge of #99216 - duarten:master, r=joshtriplett
docs: be less harsh in wording for Vec::from_raw_parts

In particular, be clear that it is sound to specify memory not
originating from a previous `Vec` allocation. That is already suggested
in other parts of the documentation about zero-alloc conversions to Box<[T]>.

Incorporate a constraint from `slice::from_raw_parts` that was missing
but needs to be fulfilled, since a `Vec` can be converted into a slice.

Fixes https://github.com/rust-lang/rust/issues/98780.
2022-10-03 20:58:53 +02:00
Scott McMurray
44b4ce1d61 Make ZST checks in core/alloc more readable
There's a bunch of these checks because of special handing for ZSTs in various unsafe implementations of stuff.

This lets them be `T::IS_ZST` instead of `mem::size_of::<T>() == 0` every time, making them both more readable and more terse.

*Not* proposed for stabilization at this time.  Would be `pub(crate)` except `alloc` wants to use it too.

(And while it doesn't matter now, if we ever get something like 85836 making it a const can help codegen be simpler.)
2022-09-22 23:12:29 -07:00
Giacomo Stevanato
fa61678a7d Fix leaking in inplace collection when destructor panics 2022-09-10 11:34:22 +02:00
Dezhi Wu
b1430fb7ca Fix a bunch of typo
This PR will fix some typos detected by [typos].

I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.

[typos]: https://github.com/crate-ci/typos
2022-08-31 18:24:55 +08:00
Maybe Waffle
53565b23ac Make use of [wrapping_]byte_{add,sub}
...replacing `.cast().wrapping_offset().cast()` & similar code.
2022-08-23 19:32:37 +04:00
Dylan DPC
4ed8fa4759
Rollup merge of #100872 - JanBeh:PR_vec_default_alloc_doc, r=fee1-dead
Add guarantee that Vec::default() does not alloc

Currently `Vec::new()` is guaranteed to not allocate until elements are pushed onto the `Vec`, but such a guarantee is missing for `Vec`'s implementation of `Default::default`.

This adds such a guarantee for `Vec::default()` to the API reference.

See also [this discussion on URLO](https://users.rust-lang.org/t/guarantee-that-vec-default-does-not-allocate/79903).
2022-08-22 20:34:16 +05:30
Dylan DPC
382ba73062
Rollup merge of #100331 - lo48576:try-reserve-preserve-on-failure, r=thomcc
Guarantee `try_reserve` preserves the contents on error

Update doc comments to make the guarantee explicit. However, some
implementations does not have the statement though.

* `HashMap`, `HashSet`: require guarantees on hashbrown side.
* `PathBuf`: simply redirecting to `OsString`.

Fixes #99606.
2022-08-22 20:34:12 +05:30
Jan Behrens
0227b71865 Add guarantee that Vec::default() does not alloc
Currently `Vec::new()` is guaranteed to not allocate until elements are
pushed onto the `Vec`, but such a guarantee is missing for `Vec`'s
implementation of `Default::default`. This adds such a guarantee for
`Vec::default()` to the API reference.
2022-08-22 12:36:44 +02:00
Matthias Krüger
a45f69f27d
Rollup merge of #100822 - WaffleLapkin:no_offset_question_mark, r=scottmcm
Replace most uses of `pointer::offset` with `add` and `sub`

As PR title says, it replaces `pointer::offset` in compiler and standard library with `pointer::add` and `pointer::sub`. This generally makes code cleaner, easier to grasp and removes (or, well, hides) integer casts.

This is generally trivially correct, `.offset(-constant)` is just `.sub(constant)`, `.offset(usized as isize)` is just `.add(usized)`, etc. However in some cases we need to be careful with signs of things.

r? ````@scottmcm````

_split off from #100746_
2022-08-21 16:54:07 +02:00
Maybe Waffle
3ba393465f Make some docs nicer wrt pointer offsets 2022-08-21 02:22:20 +04:00
Maybe Waffle
e4720e1cf2 Replace most uses of pointer::offset with add and sub 2022-08-21 02:21:41 +04:00
The 8472
bb74f97445 address review comments, add tracking issue 2022-08-13 12:58:17 +02:00
The8472
46396e847d add Vec::push_within_capacity - fallible, does not allocate 2022-08-13 10:57:22 +02:00
YOSHIOKA Takuma
2bb7e1e6ed
Guarantee try_reserve preserves the contents on error
Update doc comments to make the guarantee explicit. However, some
implementations does not have the statement though.

* `HashMap`, `HashSet`: require guarantees on hashbrown side.
* `PathBuf`: simply redirecting to `OsString`.

Fixes #99606.
2022-08-10 01:51:38 +09:00
Duarte Nunes
a85ee3ed91 add code examples 2022-07-14 11:47:06 -03:00
Duarte Nunes
8d35ab3806 rustdoc 2022-07-13 22:04:15 -03:00
Duarte Nunes
050115c0d4 typo 2022-07-13 21:49:31 -03:00
Duarte Nunes
c9ec7aa0d7 changes to wording 2022-07-13 21:48:18 -03:00
Duarte Nunes
9cd66be235 docs: be less harsh in wording for Vec::from_raw_parts
In particular, be clear that it is sound to specify memory not
originating from a previous `Vec` allocation. That is already suggested
in other parts of the documentation about zero-alloc conversions to Box<[T]>.

Incorporate a constraint from `slice::from_raw_parts` that was missing
but needs to be fulfilled, since a `Vec` can be converted into a slice.
2022-07-13 14:29:35 -03:00
bors
f99f9e48ed Auto merge of #98755 - nnethercote:faster-vec-insert, r=cuviper
Optimize `Vec::insert` for the case where `index == len`.

By skipping the call to `copy` with a zero length. This makes it closer
to `push`.

I did this recently for `SmallVec`
(https://github.com/servo/rust-smallvec/pull/282) and it was a big perf win in
one case. Although I don't have a specific use case in mind, it seems
worth doing it for `Vec` as well.

Things to note:
- In the `index < len` case, the number of conditions checked is
  unchanged.
- In the `index == len` case, the number of conditions checked increases
  by one, but the more expensive zero-length copy is avoided.
- In the `index > len` case the code now reserves space for the extra
  element before panicking. This seems like an unimportant change.

r? `@cuviper`
2022-07-03 09:36:37 +00:00
Pietro Albini
6b2d3d5f3c
update cfg(bootstrap)s 2022-07-01 15:48:23 +02:00
Nicholas Nethercote
679c5ee244 Optimize Vec::insert for the case where index == len.
By skipping the call to `copy` with a zero length. This makes it closer
to `push`.

I did this recently for `SmallVec`
(https://github.com/servo/rust-smallvec/pull/282) and it was a big perf win in
one case. Although I don't have a specific use case in mind, it seems
worth doing it for `Vec` as well.

Things to note:
- In the `index < len` case, the number of conditions checked is
  unchanged.
- In the `index == len` case, the number of conditions checked increases
  by one, but the more expensive zero-length copy is avoided.
- In the `index > len` case the code now reserves space for the extra
  element before panicking. This seems like an unimportant change.
2022-07-01 06:46:30 +10:00
jmaargh
95dc353006 Fix documentation for with_capacity and reserve families of methods
Documentation for the following methods

    with_capacity
    with_capacity_in
    with_capacity_and_hasher
    reserve
    reserve_exact
    try_reserve
    try_reserve_exact

was inconsistent and often not entirely correct where they existed on the following types

    Vec
    VecDeque
    String
    OsString
    PathBuf
    BinaryHeap
    HashSet
    HashMap
    BufWriter
    LineWriter

since the allocator is allowed to allocate more than the requested capacity in all such cases, and will frequently "allocate" much more in the case of zero-sized types (I also checked BufReader, but there the docs appear to be accurate as it appears to actually allocate the exact capacity).

Some effort was made to make the documentation more consistent between types as well.

Fix with_capacity* methods for Vec

Fix *reserve*  methods for Vec

Fix docs for *reserve* methods of VecDeque

Fix docs for String::with_capacity

Fix docs for *reserve* methods of String

Fix docs for OsString::with_capacity

Fix docs for *reserve* methods on OsString

Fix docs for with_capacity* methods on HashSet

Fix docs for *reserve methods of HashSet

Fix docs for with_capacity* methods of HashMap

Fix docs for *reserve methods on HashMap

Fix expect messages about OOM in doctests

Fix docs for BinaryHeap::with_capacity

Fix docs for *reserve* methods of BinaryHeap

Fix typos

Fix docs for with_capacity on BufWriter and LineWriter

Fix consistent use of `hasher` between `HashMap` and `HashSet`

Fix warning in doc test

Add test for capacity of vec with ZST

Fix doc test error
2022-06-19 20:46:49 +01:00
bors
20976bae5c Auto merge of #97293 - est31:remove_box, r=oli-obk
Add #[rustc_box] and use it inside alloc

This commit adds an alternative content boxing syntax, and uses it inside alloc.

```Rust
#![feature(box_syntax)]

fn foo() {
    let foo = box bar;
}
```

is equivalent to

```Rust
#![feature(rustc_attrs)]

fn foo() {
    let foo = #[rustc_box] Box::new(bar);
}
```

The usage inside the very performance relevant code in
liballoc is the only remaining relevant usage of box syntax
in the compiler (outside of tests, which are comparatively easy to port).

box syntax was originally designed to be used by all Rust
developers. This introduces a replacement syntax more tailored
to only being used inside the Rust compiler, and with it,
lays the groundwork for eventually removing box syntax.

[Earlier work](https://github.com/rust-lang/rust/pull/87781#issuecomment-894714878) by `@nbdd0121` to lower `Box::new` to `box` during THIR -> MIR building ran into borrow checker problems, requiring the lowering to be adjusted in a way that led to [performance regressions](https://github.com/rust-lang/rust/pull/87781#issuecomment-894872367). The proposed change in this PR lowers `#[rustc_box] Box::new` -> `box` in the AST -> HIR lowering step, which is way earlier in the compiler, and thus should cause less issues both performance wise as well as regarding type inference/borrow checking/etc. Hopefully, future work can move the lowering further back in the compiler, as long as there are no performance regressions.
2022-06-02 13:20:19 +00:00
bors
395a09c3da Auto merge of #97553 - nbdd0121:lib, r=Mark-Simulacrum
Add `#[inline]` to `Vec`'s `Deref/DerefMut`

This should help #97552 (although I haven't verified).
2022-06-01 04:52:11 +00:00
est31
535e28b6c6 Use #[rustc_box] in alloc instead of box syntax 2022-06-01 02:28:34 +02:00
Matthias Krüger
0d1e5465f3
Rollup merge of #97578 - ojeda:checkpatch, r=JohnTitor
alloc: remove repeated word in comment

Linux's `checkpatch.pl` reports:

```txt
#42544: FILE: rust/alloc/vec/mod.rs:2692:
WARNING: Possible repeated word: 'to'
+            // - Elements are :Copy so it's OK to to copy them, without doing
```

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-05-31 23:11:35 +02:00
bors
16a0d03698 Auto merge of #97521 - SkiFire13:clarify-vec-as-ptr, r=Dylan-DPC
Clarify the guarantees of Vec::as_ptr and Vec::as_mut_ptr when there's no allocation

Currently the documentation says they return a pointer to the vector's buffer, which has the implied precondition that the vector allocated some memory. However `Vec`'s documentation also specifies that it won't always allocate, so it's unclear whether the pointer returned is valid in that case. Of course you won't be able to read/write actual bytes to/from it since the capacity is 0, but there's an exception: zero sized read/writes. They are still valid as long as the pointer is not null and the memory it points to wasn't deallocated, but `Vec::as_ptr` and `Vec::as_mut_ptr` don't specify that's not the case. This PR thus specifies they are actually valid for zero sized reads since `Vec` is implemented to hold a dangling pointer in those cases, which is neither null nor was deallocated.
2022-05-31 12:14:51 +00:00
Miguel Ojeda
5dae6c1b96 alloc: remove repeated word in comment
Linux's `checkpatch.pl` reports:

```txt
#42544: FILE: rust/alloc/vec/mod.rs:2692:
WARNING: Possible repeated word: 'to'
+            // - Elements are :Copy so it's OK to to copy them, without doing
```

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-05-31 12:33:31 +02:00
Gary Guo
0a7a0ff4d9 Add #[inline] to Vec's Deref/DerefMut 2022-05-30 15:11:53 +01:00
Giacomo Stevanato
8ef2dd70e6 Clarify the guarantees of Vec::as_ptr and Vec::as_mut_ptr when there's no allocation 2022-05-29 17:43:35 +02:00