Commit Graph

67 Commits

Author SHA1 Message Date
bors
4ec97d991b Auto merge of #95295 - CAD97:layout-isize, r=scottmcm
Enforce that layout size fits in isize in Layout

As it turns out, enforcing this _in APIs that already enforce `usize` overflow_ is fairly trivial. `Layout::from_size_align_unchecked` continues to "allow" sizes which (when rounded up) would overflow `isize`, but these are now declared as library UB for `Layout`, meaning that consumers of `Layout` no longer have to check this before making an allocation.

(Note that this is "immediate library UB;" IOW it is valid for a future release to make this immediate "language UB," and there is an extant patch to do so, to allow Miri to catch this misuse.)

See also #95252, [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Layout.20Isn't.20Enforcing.20The.20isize.3A.3AMAX.20Rule).
Fixes https://github.com/rust-lang/rust/issues/95334

Some relevant quotes:

`@eddyb,` https://github.com/rust-lang/rust/pull/95252#issuecomment-1078513769

> [B]ecause of the non-trivial presence of both of these among code published on e.g. crates.io:
>
>   1. **`Layout` "producers" / `GlobalAlloc` "users"**: smart pointers (including `alloc::rc` copies with small tweaks), collections, etc.
>   2. **`Layout` "consumers" / `GlobalAlloc` "providers"**: perhaps fewer of these, but anything built on top of OS APIs like `mmap` will expose `> isize::MAX` allocations (on 32-bit hosts) if they lack extra checks
>
> IMO the only responsible option is to enforce the `isize::MAX` limit in `Layout`, which:
>
>   * makes `Layout` _sound_ in terms of only ever allowing allocations where `(alloc_base_ptr: *mut u8).offset(size)` is never UB
>   * frees both "producers" and "consumers" of `Layout` from manually reimplementing the checks
>     * manual checks can be risky, e.g. if the final size passed to the allocator isn't the one being checked
>     * this applies retroactively, fixing the overall soundness of existing code with zero transition period or _any_ changes required from users (as long as going through `Layout` is mandatory, making a "choke point")
>
>
> Feel free to quote this comment onto any relevant issue, I might not be able to keep track of developments.

`@Gankra,` https://github.com/rust-lang/rust/pull/95252#issuecomment-1078556371

> As someone who spent way too much time optimizing libcollections checks for this stuff and tried to splatter docs about it everywhere on the belief that it was a reasonable thing for people to manually take care of: I concede the point, it is not reasonable. I am wholy spiritually defeated by the fact that _liballoc_ of all places is getting this stuff wrong. This isn't throwing shade at the folks who implemented these Rc features, but rather a statement of how impractical it is to expect anyone out in the wider ecosystem to enforce them if _some of the most audited rust code in the library that defines the very notion of allocating memory_ can't even reliably do it.
>
> We need the nuclear option of Layout enforcing this rule. Code that breaks this rule is _deeply_ broken and any "regressions" from changing Layout's contract is a _correctness_ fix. Anyone who disagrees and is sufficiently motivated can go around our backs but the standard library should 100% refuse to enable them.

cc also `@RalfJung` `@rust-lang/wg-allocators.` Even though this technically supersedes #95252, those potential failure points should almost certainly still get nicer panics than just "unwrap failed" (which they would get by this PR).

It might additionally be worth recommending to users of the `Layout` API that they should ideally use `.and_then`/`?` to complete the entire layout calculation, and then `panic!` from a single location at the end of `Layout` manipulation, to reduce the overhead of the checks and optimizations preserving the exact location of each `panic` which are conceptually just one failure: allocation too big.

Probably deserves a T-lang and/or T-libs-api FCP (this technically solidifies the [objects must be no larger than `isize::MAX`](https://rust-lang.github.io/unsafe-code-guidelines/layout/scalars.html#isize-and-usize) rule further, and the UCG document says this hasn't been RFCd) and a crater run. Ideally, no code exists that will start failing with this addition; if it does, it was _likely_ (but not certainly) causing UB.

Changes the raw_vec allocation path, thus deserves a perf run as well.

I suggest hiding whitespace-only changes in the diff view.
2022-07-10 08:54:32 +00: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
est31
7230a15c32 Use Box::new() instead of box syntax in alloc tests 2022-05-29 00:41:14 +02:00
Cyborus04
06788fd7a4 add <[[T; N]]>::flatten, <[[T; N]]>::flatten_mut, and Vec::<[T; N]>::into_flattened 2022-04-08 00:54:39 -04:00
Jörn Horstmann
d9a438dc73 Add another assertion without into_iter 2022-03-25 16:57:59 +01:00
Jörn Horstmann
4b53f563bd Add a test verifying the number of drop calls 2022-03-25 13:28:19 +01:00
CAD97
7b58193f90 Adjust tests for isize::MAX allocation always being checked 2022-03-25 00:57:05 -05:00
T-O-R-U-S
72a25d05bf Use implicit capture syntax in format_args
This updates the standard library's documentation to use the new syntax. The
documentation is worthwhile to update as it should be more idiomatic
(particularly for features like this, which are nice for users to get acquainted
with). The general codebase is likely more hassle than benefit to update: it'll
hurt git blame, and generally updates can be done by folks updating the code if
(and when) that makes things more readable with the new format.

A few places in the compiler and library code are updated (mostly just due to
already having been done when this commit was first authored).
2022-03-10 10:23:40 -05:00
Lucas Kent
08829853d3 eplace usages of vec![].into_iter with [].into_iter 2022-01-09 14:09:25 +11:00
The8472
3f9b26dc64 Fix Iterator::advance_by contract inconsistency
The `advance_by(n)` docs state that in the error case `Err(k)` that k is always less than n.
It also states that `advance_by(0)` may return `Err(0)` to indicate an exhausted iterator.
These statements are inconsistent.
Since only one implementation (Skip) actually made use of that I changed it to return Ok(()) in that case too.

While adding some tests I also found a bug in `Take::advance_back_by`.
2021-11-19 13:00:23 +01:00
The8472
2c6e67105e implement advance_(back_)_by on more iterators 2021-09-30 21:23:28 +02:00
Kornel
7dca8eb565 Use assert_matches! instead of if let {} else 2021-08-07 14:48:27 +01:00
Kornel
a294aa8d3d Hide allocator details from TryReserveError 2021-07-24 22:25:08 +01:00
hi-rustin
88abd7d81d Lint for unused borrows as part of UNUSED_MUST_USE 2021-06-18 15:09:40 +08:00
Muhammad Mominul Huque
507d97b26e Update expressions where we can use array's IntoIterator implementation 2021-06-02 16:09:04 +06:00
Giacomo Stevanato
c9595faa28 Make Vec::dedup panicking test actually detect double panics 2021-05-24 12:42:04 +02:00
the8472
7cb4e5180f from review: more robust test
This also checks the contents and not only the capacity in case IntoIter's clone implementation is changed to add capacity at the end. Extra capacity at the beginning would be needed to make InPlaceIterable work.

Co-authored-by: Giacomo Stevanato <giaco.stevanato@gmail.com>
2021-05-19 01:41:12 +02:00
The8472
a44a059c3b add regression test 2021-05-19 01:41:12 +02:00
The8472
60a900ee10 remove InPlaceIterable marker from Peekable due to unsoundness
The unsoundness is not in Peekable per se, it rather is due to the
interaction between Peekable being able to hold an extra item
and vec::IntoIter's clone implementation shortening the allocation.

An alternative solution would be to change IntoIter's clone implementation
to keep enough spare capacity available.
2021-05-19 01:41:09 +02:00
Dylan DPC
b943ea8cdc
Rollup merge of #83827 - the8472:fix-inplace-panic-on-drop, r=RalfJung
cleanup leak after test to make miri happy

Contains changes that were requested in #83629 but didn't make it into the rollup.

r? `````@RalfJung`````
2021-04-04 19:20:06 +02:00
Dylan DPC
869726d335
Rollup merge of #81619 - SkiFire13:resultshunt-inplace, r=the8472
Implement `SourceIterator` and `InPlaceIterable` for `ResultShunt`
2021-04-04 19:19:59 +02:00
the8472
572873fce0
suggestion from review
Co-authored-by: Ralf Jung <post@ralfj.de>
2021-04-04 01:38:58 +02:00
The8472
3bd241f95b cleanup leak after test to make miri happy 2021-04-04 01:37:05 +02:00
The8472
fa89c0fbcf add testcase for double-drop during Vec in-place collection 2021-03-29 04:39:23 +02:00
Soveu
b0092bc995 Vec::dedup optimization - add benches 2021-03-16 14:41:26 +01:00
Soveu
96d6f22a8e
Merge branch 'master' into dedup 2021-03-15 21:51:38 +01:00
Soveu
2285f11724 Vec::dedup optimization - add test for panic 2021-03-15 21:26:22 +01:00
Soveu
2abab1f688 Vec::dedup optimization - add tests 2021-03-15 20:24:35 +01:00
Waffle
1f031d95de Add regression test for Vec::extend_from_within leak 2021-03-04 17:10:57 +03:00
Waffle
9c4e3af39d Add test that Vec::spare_capacity_mut doesn't invalidate pointers 2021-03-03 01:00:59 +03:00
Hanif Bin Ariffin
fa9af6a9be Added tests to drain an empty vec
Discovered this kind of issue in an unrelated library.
The author copied the tests from here and AFAIK, there are no tests for this particular case.

Signed-off-by: Hanif Bin Ariffin <hanif.ariffin.4326@gmail.com>
2021-02-13 11:18:36 +08:00
bors
1efd804983 Auto merge of #81126 - oxalica:retain-early-drop, r=m-ou-se
Optimize Vec::retain

Use `copy_non_overlapping` instead of `swap` to reduce memory writes, like what we've done in #44355 and `String::retain`.
#48065 already tried to do this optimization but it is reverted in #67300 due to bad codegen of `DrainFilter::drop`.

This PR re-implement the drop-then-move approach. I did a [benchmark](https://gist.github.com/oxalica/3360eec9376f22533fcecff02798b698) on small-no-drop, small-need-drop, large-no-drop elements with different predicate functions. It turns out that the new implementation is >20% faster in average for almost all cases. Only 2/24 cases are slower by 3% and 5%. See the link above for more detail.

I think regression in may-panic cases is due to drop-guard preventing some optimization. If it's permitted to leak elements when predicate function of element's `drop` panic, the new implementation should be almost always faster than current one.
I'm not sure if we should leak on panic, since there is indeed an issue (#52267) complains about it before.
2021-02-11 04:40:57 +00:00
Giacomo Stevanato
2fb56cc123 Update test to collect item with a different type than the original vec 2021-02-03 21:00:07 +01:00
Giacomo Stevanato
c6c8f3bf12 Move test 2021-02-01 17:16:54 +01:00
Waffle
d5c221107e add Vec::extend_from_within method
Implement <https://github.com/rust-lang/rfcs/pull/2714>, changes from the RFC:
- Rename the method `append_from_within` => `extend_from_within`
- Loose :Copy bound => :Clone
- Specialize in case of :Copy

This commit also adds `Vec::split_at_spare` private method and use it to implement
`Vec::spare_capacity_mut` and `Vec::extend_from_within`. This method returns 2
slices - initialized elements (same as `&mut vec[..]`) and uninitialized but
allocated space (same as `vec.spare_capacity_mut()`).
2021-01-31 22:30:19 +03:00
oxalica
969e552355
Simplify and fix tests 2021-01-24 00:11:51 +08:00
oxalica
d6dec1ebe3
Optimize Vec::retain 2021-01-18 01:48:50 +08:00
Aaron Hill
6f91c32da6
Fix new 'unnecessary trailing semicolon' warnings 2020-11-26 17:08:36 -05:00
Alexis Bourget
42271a537a Move vec swap test 2020-10-17 18:48:20 +02:00
Alexis Bourget
4fd06b9bb5 Move vec-macro-repeat test 2020-10-17 18:48:20 +02:00
Alexis Bourget
4af560ecef Move zero-sized-vec-push test 2020-10-17 18:42:14 +02:00
bors
5779815f89 Auto merge of #74194 - mbrubeck:slice-eq, r=sfackler
Add PartialEq impls for Vec <-> slice

This is a follow-up to #71660 and rust-lang/rfcs#2917 to add two more missing vec/slice PartialEq impls:

```
impl<A, B> PartialEq<[B]> for Vec<A> where A: PartialEq<B> { .. }
impl<A, B> PartialEq<Vec<B>> for [A] where A: PartialEq<B> { .. }
```

Since this is insta-stable, it should go through the `@rust-lang/libs` FCP process.  Note that I used version 1.47.0 for the `stable` attribute because I assume this will not merge before the 1.46.0 branch is cut next week.
2020-10-07 01:20:11 +00:00
Alexis Bourget
f6a4189d05 Move vec-cycle-wrapped test 2020-09-21 21:50:27 +02:00
Alexis Bourget
6bc0357dad Move vec-cycle test 2020-09-21 21:50:27 +02:00
Mara Bos
1e2dba1e7c Use T::BITS instead of size_of::<T> * 8. 2020-09-19 06:54:42 +02:00
Ralf Jung
9d0a265b6c
Rollup merge of #76662 - RalfJung:lib-test-miri, r=Mark-Simulacrum
Fix liballoc test suite for Miri

Mostly, fix the regression introduced by https://github.com/rust-lang/rust/pull/75207 that caused slices (i.e., references) to be created to invalid memory or memory that has aliasing pointers that we want to keep valid. @dylni  this changes the type of `check_range` to only require the length, not the full reference to the slice, which indeed is all the information this function requires.

Also reduce the size of a test introduced in https://github.com/rust-lang/rust/pull/70793 to make it not take 3 minutes in Miri.

This makes https://github.com/RalfJung/miri-test-libstd work again.
2020-09-16 08:25:02 +02:00
Dylan DPC
fb9bb2b5ca
Rollup merge of #75146 - tmiasko:range-overflow, r=Mark-Simulacrum
Detect overflow in proc_macro_server subspan

* Detect overflow in proc_macro_server subspan
* Add tests for overflow in Vec::drain
* Add tests for overflow in String / VecDeque operations using ranges
2020-09-16 01:30:30 +02:00
Ralf Jung
c528d24196 fix slice::check_range aliasing problems 2020-09-15 23:14:41 +02:00
Ralf Jung
d888725fba reduce size of test_from_iter_specialization_with_iterator_adapters test in Miri 2020-09-15 23:03:07 +02:00
bors
6cae28165f Auto merge of #76682 - richkadel:vec-take, r=Mark-Simulacrum
Optimize behavior of vec.split_off(0) (take all)

Optimization improvement to `split_off()` so the performance meets the
intuitively expected behavior when `at == 0`, avoiding the current behavior
of copying the entire vector.

The change honors documented behavior that the original vector's
"previous capacity unchanged".

This improvement better supports the pattern for building and flushing a
buffer of elements, such as the following:

```rust
    let mut vec = Vec::new();
    loop {
        vec.push(something);
        if condition_is_met {
            process(vec.split_off(0));
        }
    }
```

`Option` wrapping is the first alternative I thought of, but is much
less obvious and more verbose:

```rust
    let mut capacity = 1;
    let mut vec: Option<Vec<Stuff>> = None;
    loop {
        vec.get_or_insert_with(|| Vec::with_capacity(capacity)).push(something);
        if condition_is_met {
            capacity = vec.capacity();
            process(vec.take().unwrap());
        }
    }
```

Directly using `mem::replace()` (instead of  calling`split_off()`) could work,
but `mem::replace()` is a more advanced tool for Rust developers, and in
this case, I believe developers would assume the standard library should
be sufficient for the purpose described here.

The benefit of the approach to this change is it does not change the
existing API contract, but improves the peformance of `split_off(0)` for
`Vec`, `String` (which delegates `split_off()` to `Vec`), and any other
existing use cases.

This change adds tests to validate the behavior of `split_off()` with
regard to capacity, as originally documented, and confirm that behavior
still holds, when `at == 0`.

The change is an implementation detail, and does not require a
documentation change, but documenting the new behavior as part of its
API contract may benefit future users.

(Let me know if I should make that documentation update.)

Note, for future consideration:

I think it would be helpful to introduce an additional method to `Vec`
(if not also to `String`):

```
    pub fn take_all(&mut self) -> Self {
        self.split_off(0)
    }
```

This would make it more clear how `Vec` supports the pattern, and make
it easier to find, since the behavior is similar to other `take()`
methods in the Rust standard library.

r? `@wesleywiser`
FYI: `@tmandry`
2020-09-15 05:01:17 +00:00