Commit Graph

2084 Commits

Author SHA1 Message Date
Matthias Krüger
47ccca0c86
Rollup merge of #106992 - joboet:alloc_remove_box_syntax, r=thomcc
Remove unused `#![feature(box_syntax)]` in `alloc`
2023-01-18 06:59:21 +01:00
Markus Everling
ccba6c5151 Add vec_deque::IntoIter benchmarks 2023-01-18 00:33:05 +01:00
The 8472
47014b1bb9 Don't do pointer arithmetic on pointers to deallocated memory
vec::Splice can invalidate the slice::Iter inside vec::Drain.
So we replace them with dangling pointers which, unlike ones to
deallocated memory, are allowed.
2023-01-17 22:01:33 +01:00
joboet
be9c363066
refactor[alloc]: remove unused box syntax feature 2023-01-17 18:55:44 +01:00
Chayim Refael Friedman
8dbc878a35
Avoid unsafe code in to_ascii_[lower/upper]case() 2023-01-16 01:15:06 +02:00
David Tolnay
fa2ff4d7e5
Rebuild BinaryHeap on unwind from retain 2023-01-15 13:20:00 -08:00
David Tolnay
0d3eaa848c
Add test showing broken behavior of BinaryHeap::retain 2023-01-15 13:12:28 -08:00
bors
bbb36fe545 Auto merge of #105851 - dtolnay:peekmutleak, r=Mark-Simulacrum
Leak amplification for peek_mut() to ensure BinaryHeap's invariant is always met

In the libs-api team's discussion around #104210, some of the team had hesitations around exposing malformed BinaryHeaps of an element type whose Ord and Drop impls are trusted, and which does not contain interior mutability.

For example in the context of this kind of code:

```rust
use std::collections::BinaryHeap;
use std::ops::Range;
use std::slice;

fn main() {
    let slice = &mut ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'];
    let cut_points = BinaryHeap::from(vec![4, 2, 7]);
    println!("{:?}", chop(slice, cut_points));
}

// This is a souped up slice::split_at_mut to split in arbitrary many places.
//
// usize's Ord impl is trusted, so 1 single bounds check guarantees all those
// output slices are non-overlapping and in-bounds
fn chop<T>(slice: &mut [T], mut cut_points: BinaryHeap<usize>) -> Vec<&mut [T]> {
    let mut vec = Vec::with_capacity(cut_points.len() + 1);
    let max = match cut_points.pop() {
        Some(max) => max,
        None => {
            vec.push(slice);
            return vec;
        }
    };

    assert!(max <= slice.len());

    let len = slice.len();
    let ptr: *mut T = slice.as_mut_ptr();
    let get_unchecked_mut = unsafe {
        |range: Range<usize>| &mut *slice::from_raw_parts_mut(ptr.add(range.start), range.len())
    };

    vec.push(get_unchecked_mut(max..len));
    let mut end = max;
    while let Some(start) = cut_points.pop() {
        vec.push(get_unchecked_mut(start..end));
        end = start;
    }
    vec.push(get_unchecked_mut(0..end));
    vec
}
```

```console
[['7', '8', '9'], ['4', '5', '6'], ['2', '3'], ['0', '1']]
```

In the current BinaryHeap API, `peek_mut()` is the only thing that makes the above function unsound.

```rust
let slice = &mut ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'];
let mut cut_points = BinaryHeap::from(vec![4, 2, 7]);
{
    let mut max = cut_points.peek_mut().unwrap();
    *max = 0;
    std::mem::forget(max);
}
println!("{:?}", chop(slice, cut_points));
```

```console
[['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'], [], ['2', '3'], ['0', '1']]
```

Or worse:

```rust
let slice = &mut ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'];
let mut cut_points = BinaryHeap::from(vec![100, 100]);
{
    let mut max = cut_points.peek_mut().unwrap();
    *max = 0;
    std::mem::forget(max);
}
println!("{:?}", chop(slice, cut_points));
```

```console
[['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'], [], ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '\u{1}', '\0', '?', '翾', '?', '翾', '\0', '\0', '?', '翾', '?', '翾', '?', '啿', '?', '啿', '?', '啿', '?', '啿', '?', '啿', '?', '翾', '\0', '\0', '񤬐', '啿', '\u{5}', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\u{8}', '\0', '`@',` '\0', '\u{1}', '\0', '?', '翾', '?', '翾', '?', '翾', '
thread 'main' panicked at 'index out of bounds: the len is 33 but the index is 33', library/core/src/unicode/unicode_data.rs:319:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

---

This PR makes `peek_mut()` use leak amplification (https://doc.rust-lang.org/1.66.0/nomicon/leaking.html#drain) to preserve the heap's invariant even in the situation that `PeekMut` gets leaked.

I'll also follow up in the tracking issue of unstable `drain_sorted()` (#59278) and `retain()` (#71503).
2023-01-15 08:59:55 +00:00
David Tolnay
23501703fb
Document guarantees about BinaryHeap invariant 2023-01-14 13:28:30 -08:00
David Tolnay
aedb756020
Leak amplification for peek_mut() to ensure BinaryHeap's invariant is always met 2023-01-14 13:28:22 -08:00
David Tolnay
4fe167f83a
Add test of leaking a binary_heap PeekMut 2023-01-14 13:28:14 -08:00
André Vennberg
0b35f448f8 Remove various double spaces in source comments. 2023-01-14 17:22:04 +01:00
Lukas Markeffsky
76e216f29b Use associated items of char instead of freestanding items in core::char 2023-01-14 11:58:41 +01:00
Yuki Okushi
feac18c0d6
Rollup merge of #106692 - eggyal:mv-binary_heap.rs-binary_heap/mod.rs, r=Mark-Simulacrum
mv binary_heap.rs binary_heap/mod.rs

I confess this request is somewhat selfish, as it's made in order to ease synchronisation with my [copse](https://crates.io/crates/copse) crate (see eggyal/copse#6 for explanation). I wholly understand that such grounds may be insufficient to justify merging this request—but no harm in asking, right?
2023-01-14 12:04:33 +09:00
Alan Egerton
1a87ed9a45
mv binary_heap.rs binary_heap/mod.rs 2023-01-10 18:01:39 +00:00
Ezra Shaw
203bbfa2f7
impl: specialize impl of ToString on bool 2023-01-10 15:34:21 +13:00
Michael Goulet
70f1566b2b
Rollup merge of #106584 - kpreid:vec-allocator, r=JohnTitor
Document that `Vec::from_raw_parts[_in]` must be given a pointer from the correct allocator.

Currently, the documentation of `Vec::from_raw_parts` and `Vec::from_raw_parts_in` says nothing about what allocator the pointer must come from. This PR adds that missing information explicitly.
2023-01-08 19:57:54 -08:00
bors
a377893da2 Auto merge of #90291 - geeklint:loosen_weak_debug_bound, r=dtolnay
Loosen the bound on the Debug implementation of Weak.

Both `rc::Weak<T>` and `sync::Weak<T>` currently require `T: Debug` in their own `Debug` implementations, but they don't currently use it;  they only ever print a fixed string.

A general implementation of Debug for Weak that actually attempts to upgrade and rely on the contents is unlikely in the future because it may have unbounded recursion in the presence of reference cycles, which Weak is commonly used in.  (This was the justification for why the current implementation [was implemented the way it is](f0976e2cf3)).

When I brought it up [on the forum](https://internals.rust-lang.org/t/could-the-bound-on-weak-debug-be-relaxed/15504), it was suggested that, even if an implementation is specialized in the future that relies on the data stored within the Weak, it would likely rely on specialization anyway, and could therefore easily specialize on the Debug bound as well.
2023-01-08 22:40:38 +00:00
Yuki Okushi
14ce60333d
Rollup merge of #106562 - clubby789:vec-deque-example, r=Mark-Simulacrum
Clarify examples for `VecDeque::get/get_mut`

Closes #106114

``@rustbot`` label +A-docs
2023-01-08 17:01:48 +09:00
bors
2afe58571e Auto merge of #104658 - thomcc:rand-update-and-usable-no_std, r=Mark-Simulacrum
Update `rand` in the stdlib tests, and remove the `getrandom` feature from it.

The main goal is actually removing `getrandom`, so that eventually we can allow running the stdlib test suite on tier3 targets which don't have `getrandom` support. Currently those targets can only run the subset of stdlib tests that exist in uitests, and (generally speaking), we prefer not to test libstd functionality in uitests, which came up recently in https://github.com/rust-lang/rust/pull/104095 and https://github.com/rust-lang/rust/pull/104185. Additionally, the fact that we can't update `rand`/`getrandom` means we're stuck with the old set of tier3 targets, so can't test new ones.

~~Anyway, I haven't checked that this actually does allow use on tier3 targets (I think it does not, as some work is needed in stdlib submodules) but it moves us slightly closer to this, and seems to allow at least finally updating our `rand` dep, which definitely improves the status quo.~~ Checked and works now.

For the most part, our tests and benchmarks are fine using hard-coded seeds. A couple tests seem to fail with this (stuff manipulating the environment expecting no collisions, for example), or become pointless (all inputs to a function become equivalent). In these cases I've done a (gross) dance (ab)using `RandomState` and `Location::caller()` for some extra "entropy".

Trying to share that code seems *way* more painful than it's worth given that the duplication is a 7-line function, even if the lines are quite gross. (Keeping in mind that sharing it would require adding `rand` as a non-dev dep to std, and exposing a type from it publicly, all of which sounds truly awful, even if done behind a perma-unstable feature).

See also some previous attempts:
- https://github.com/rust-lang/rust/pull/86963 (in particular https://github.com/rust-lang/rust/pull/86963#issuecomment-885438936 which explains why this is non-trivial)
- https://github.com/rust-lang/rust/pull/89131
- https://github.com/rust-lang/rust/pull/96626#issuecomment-1114562857 (I tried in that PR at the same time, but settled for just removing the usage of `thread_rng()` from the benchmarks, since that was the main goal).
- https://github.com/rust-lang/rust/pull/104185
- Probably more. It's very tempting of a thing to "just update".

r? `@Mark-Simulacrum`
2023-01-08 01:34:05 +00: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
Matthias Krüger
d7519c3639
Rollup merge of #105128 - Sp00ph:vec_vec_deque_conversion, r=dtolnay
Add O(1) `Vec -> VecDeque` conversion guarantee

(See #105072)
2023-01-07 20:43:20 +01:00
clubby789
fed349957d Clarify examples for VecDeque::get/get_mut 2023-01-07 14:38:21 +00:00
Thom Chiovoloni
a4bf36e87b
Update rand in the stdlib tests, and remove the getrandom feature from it 2023-01-04 14:52:41 -08:00
bors
df756439df Auto merge of #106239 - LegionMammal978:thin-box-drop-guard, r=Amanieu
Deallocate ThinBox even if the value unwinds on drop

This makes it match the behavior of an ordinary `Box`.
2023-01-04 12:55:22 +00:00
Michael Goulet
f6b0f4707b
Rollup merge of #106045 - RalfJung:oom-nounwind-panic, r=Amanieu
default OOM handler: use non-unwinding panic, to match std handler

The OOM handler in std will by default abort. This adjusts the default in liballoc to do the same, using the `can_unwind` flag on the panic info to indicate a non-unwinding panic.

In practice this probably makes little difference since the liballoc default will only come into play in no-std situations where people write a custom panic handler, which most likely will not implement unwinding. But still, this seems more consistent.

Cc `@rust-lang/wg-allocators,` https://github.com/rust-lang/rust/issues/66741
2023-01-03 17:19:26 -08:00
Ralf Jung
5974f6f0a5 default OOM handler: use non-unwinding panic (unless -Zoom=panic is set), to match std handler 2023-01-02 16:35:14 +01:00
LegionMammal978
ce28b4d408 Deallocate ThinBox even if the value unwinds on drop 2023-01-01 13:48:18 -05:00
Michael Goulet
5b74a33b8d
Rollup merge of #106248 - dtolnay:revertupcastlint, r=jackh726
Revert "Implement allow-by-default `multiple_supertrait_upcastable` lint"

This is a clean revert of #105484.

I confirmed that reverting that PR fixes the regression reported in #106247. ~~I can't say I understand what this code is doing, but maybe it can be re-landed with a different implementation.~~ **Edit:** https://github.com/rust-lang/rust/issues/106247#issuecomment-1367174384 has an explanation of why #105484 ends up surfacing spurious `where_clause_object_safety` errors. The implementation of `where_clause_object_safety` assumes we only check whether a trait is object safe when somebody actually uses that trait with `dyn`. However the implementation of `multiple_supertrait_upcastable` added in the problematic PR involves checking *every* trait for whether it is object-safe.

FYI `@nbdd0121` `@compiler-errors`
2022-12-30 21:26:34 -08:00
jonathanCogan
78691e3589 Update paths in comments. 2022-12-30 14:00:42 +01:00
jonathanCogan
db47071df2 Replace libstd, libcore, liballoc in line comments. 2022-12-30 14:00:42 +01:00
jonathanCogan
72067c77bd Replace libstd, libcore, liballoc in docs. 2022-12-30 14:00:40 +01:00
David Tolnay
06ec0bf8b0
Revert "Implement allow-by-default multiple_supertrait_upcastable lint"
This reverts commit 5e44a65517.
2022-12-29 00:47:23 -08:00
Markus Everling
7c13b145f4 Implement more methods for vec_deque::IntoIter 2022-12-29 03:00:11 +01:00
Lukas Markeffsky
f4ff423d67 fix documenting private items of standard library 2022-12-28 09:18:43 -05:00
Pietro Albini
11191279b7 Update bootstrap cfg 2022-12-28 09:18:43 -05:00
fee1-dead
8b3d0c4cf9
Rollup merge of #105484 - nbdd0121:upcast, r=compiler-errors
Implement allow-by-default `multiple_supertrait_upcastable` lint

The lint detects when an object-safe trait has multiple supertraits.

Enabled in libcore and liballoc as they are low-level enough that many embedded programs will use them.

r? `@nikomatsakis`
2022-12-28 15:51:41 +08:00
fee1-dead
58233e90b8
Rollup merge of #104024 - noeddl:unused-must-use, r=compiler-errors
Fix `unused_must_use` warning for `Box::from_raw`
2022-12-28 15:51:39 +08:00
fee1-dead
dc98aa681f
Rollup merge of #94145 - ssomers:binary_heap_tests, r=jyn514
Test leaking of BinaryHeap Drain iterators

Add test cases about forgetting the `BinaryHeap::Drain` iterator, and slightly fortifies some other test cases.

Consists of separate commits that I don't think are relevant on their own (but I'll happily turn these into more PRs if desired).
2022-12-28 15:51:37 +08: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
Ralf Jung
6fb314ed7d add lib tests for vec::IntoIter alignment issues 2022-12-24 10:08:27 +01:00
Ralf Jung
a48d2e1783 fix one more unaligned self.ptr, and add tests 2022-12-23 15:49:23 +01:00
Ralf Jung
d0f404d77a fix IntoIter::drop on high-alignment ZST 2022-12-23 15:18:18 +01:00
bors
1d12c3cea3 Auto merge of #105127 - Sp00ph:const_new, r=dtolnay
Make `VecDeque::new` const

(See #105072)
2022-12-20 20:25:42 +00:00
Anders Kaseorg
8c73ce6611 Update coerce_unsized tracking issue from #27732 to #18598
Issue #27732 was closed as a duplicate of #18598.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
2022-12-19 23:09:47 -08:00
Evan Jones
ab2151cbf8 std::fmt: Use args directly in example code
The lint "clippy::uninlined_format_args" recommends inline
variables in format strings. Fix two places in the docs that do
not do this. I noticed this because I copy/pasted one example in
to my project, then noticed this lint error. This fixes:

error: variables can be used directly in the `format!` string
  --> src/main.rs:30:22
   |
30 |         let string = format!("{:.*}", decimals, magnitude);
   |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: variables can be used directly in the `format!` string
  --> src/main.rs:39:2
   |
39 |  write!(&mut io::stdout(), "{}", args).unwrap();
2022-12-17 13:43:08 -05:00
Hannes Körber
9671dd239d doc: Fix a few small issues
* A few typos around generic types (`;` vs `,`)
* Use inline code formatting for code fragments
* One instance of wrong wording
2022-12-15 14:05:03 +01:00
Scott McMurray
6648134434 Apply review feedback; Fix no_global_oom_handling build 2022-12-08 22:08:55 -08:00
Gary Guo
5e44a65517 Implement allow-by-default multiple_supertrait_upcastable lint 2022-12-09 02:29:51 +00:00
Scott McMurray
58e60ac211 Make VecDeque::from_iter O(1) from vec(_deque)::IntoIter 2022-12-08 01:42:45 -08:00
Markus Everling
ac583f18b7 Add O(1) Vec -> VecDeque conversion guarantee 2022-12-05 14:57:22 +01:00
bors
203c8765ea Auto merge of #105046 - scottmcm:vecdeque-vs-vec, r=Mark-Simulacrum
Send `VecDeque::from_iter` via `Vec::from_iter`

Since it's O(1) to convert between them now, might as well reuse the logic.

Mostly for the various specializations it does, but might also save some monomorphization work if, say, people collect slice iterators into both `Vec`s and `VecDeque`s.
2022-12-05 08:45:03 +00:00
Yuki Okushi
9f3ccd4bf6
Rollup merge of #105032 - HintringerFabian:improve_docs, r=JohnTitor
improve doc of into_boxed_slice and impl From<Vec<T>> for Box<[T]>

Improves description of `into_boxed_slice`, and adds example to `impl From<Vec<T>> for Box<[T]>`.
Fixes #98908
2022-12-03 12:51:27 +09:00
Markus Everling
c959fbe771 Fix typo in comment 2022-12-01 12:44:29 +01:00
Markus Everling
2fba07842b Make VecDeque::new const 2022-12-01 12:41:31 +01:00
Markus Everling
929003aacf Make VecDeque::new_in unstably const 2022-12-01 12:15:29 +01:00
Scott McMurray
a964a37211 Send VecDeque::from_iter via Vec::from_iter
Since it's O(1) to convert between them now, might as well reuse the logic.

Mostly for the various specializations it does, but might also save some monomorphization work if, say, people collect slice iterators into both `Vec`s and `VecDeque`s.
2022-11-29 00:24:15 -08:00
Fabian Hintringer
f9490c8121 improve doc 2022-11-28 22:42:05 +01:00
bors
69df0f2c2f Auto merge of #102991 - Sp00ph:master, r=scottmcm
Update VecDeque implementation to use head+len instead of head+tail

(See #99805)

This changes `alloc::collections::VecDeque`'s internal representation from using head and tail indices to using a head index and a length field. It has a few advantages over the current design:
* It allows the buffer to be of length 0, which means the `VecDeque::new` new longer has to allocate and could be changed to a `const fn`
* It allows the `VecDeque` to fill the buffer completely, unlike the old implementation, which always had to leave a free space
* It removes the restriction for the size to be a power of two, allowing it to properly `shrink_to_fit`, unlike the old `VecDeque`
* The above points also combine to allow the `Vec<T> -> VecDeque<T>` conversion to be very cheap and guaranteed O(1). I mention this in the `From<Vec<T>>` impl, but it's not a strong guarantee just yet, as that would likely need some form of API change proposal.

All the tests seem to pass for the new `VecDeque`, with some slight adjustments.

r? `@scottmcm`
2022-11-28 10:39:47 +00:00
bors
faf1891deb Auto merge of #104818 - scottmcm:refactor-extend-func, r=the8472
Stop peeling the last iteration of the loop in `Vec::resize_with`

`resize_with` uses the `ExtendWith` code that peels the last iteration:
341d8b8a2c/library/alloc/src/vec/mod.rs (L2525-L2529)

But that's kinda weird for `ExtendFunc` because it does the same thing on the last iteration anyway:
341d8b8a2c/library/alloc/src/vec/mod.rs (L2494-L2502)

So this just has it use the normal `extend`-from-`TrustedLen` code instead.

r? `@ghost`
2022-11-27 00:58:50 +00:00
Markus Everling
acf95adfe2 Add second test case in make_contiguous_head_to_end 2022-11-26 23:08:57 +01:00
Markus Everling
451259811a Improve slow path in make_contiguous 2022-11-26 22:55:39 +01:00
Markus Everling
f6f25983c6 Don't use Take in SpecExtend impl 2022-11-26 00:44:24 +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
Markus Everling
ecca8c5328 Changes according to code review 2022-11-25 03:39:59 +01: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
Thom Chiovoloni
54a6d4edbc
Add #![deny(unsafe_op_in_unsafe_fn)] in liballoc tests 2022-11-23 08:10:17 -08:00
Manish Goregaokar
316bda89e4
Rollup merge of #104647 - RalfJung:alloc-strict-provenance, r=thomcc
enable fuzzy_provenance_casts lint in liballoc and libstd

r? ````@thomcc````
2022-11-22 22:54:41 -05:00
The 8472
d576a9b241 add test for issue 104726 2022-11-22 20:58:43 +01:00
Manish Goregaokar
2f8dbe3797
Rollup merge of #101655 - dns2utf8:box_docs, r=dtolnay
Make the Box one-liner more descriptive

I would like to avoid a definition that relies on itself.

r? `@GuillaumeGomez`
2022-11-22 01:26:06 -05:00
David Tolnay
70cee5af4b
Touch up Box<T> one-liner 2022-11-21 15:28:41 -08:00
Matthias Krüger
9a9569698b
Rollup merge of #104641 - tshepang:grammar, r=Mark-Simulacrum
replace unusual grammar
2022-11-20 23:50:29 +01:00
Matthias Krüger
b4513ce6f8
Rollup merge of #101310 - zachs18:rc_get_unchecked_mut_docs_soundness, r=Mark-Simulacrum
Clarify and restrict when `{Arc,Rc}::get_unchecked_mut` is allowed.

(Tracking issue for `{Arc,Rc}::get_unchecked_mut`: #63292)

(I'm using `Rc` in this comment, but it applies for `Arc` all the same).

As currently documented, `Rc::get_unchecked_mut` can lead to unsoundness when multiple `Rc`/`Weak` pointers to the same allocation exist. The current documentation only requires that other `Rc`/`Weak` pointers to the same allocation "must not be dereferenced for the duration of the returned borrow". This can lead to unsoundness in (at least) two ways: variance, and `Rc<str>`/`Rc<[u8]>` aliasing. ([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=d7e2d091c389f463d121630ab0a37320)).

This PR changes the documentation of `Rc::get_unchecked_mut` to restrict usage to when all `Rc<T>`/`Weak<T>` have the exact same `T` (including lifetimes). I believe this is sufficient to prevent unsoundness, while still allowing `get_unchecked_mut` to be called on an aliased `Rc` as long as the safety contract is upheld by the caller.

## Alternatives

* A less strict, but still sound alternative would be to say that the caller must only write values which are valid for all aliased `Rc`/`Weak` inner types. (This was [mentioned](https://github.com/rust-lang/rust/issues/63292#issuecomment-568284090) in the tracking issue). This may be too complicated to clearly express in the documentation.
* A more strict alternative would be to say that there must not be any aliased `Rc`/`Weak` pointers, i.e. it is required that get_mut would return `Some(_)`. (This was also mentioned in the tracking issue). There is at least one codebase that this would cause to become unsound ([here](be5a164d77/src/memtable.rs (L166)), where additional locking is used to ensure unique access to an aliased `Rc<T>`;  I saw this because it was linked on the tracking issue).
2022-11-20 23:50:26 +01:00
Lukas Bergdoll
dbc0ed2a10 Unify stable and unstable sort implementations in same core module
This moves the stable sort implementation to the core::slice::sort module. By
virtue of being in core it can't access `Vec`. The two `Vec` used by merge sort,
`buf` and `runs`, are modelled as custom types that implement the very limited
required `Vec` interface with the help of provided allocation and free
functions. This is done to allow future re-use of functions and logic between
stable and unstable sort. Such as `insert_head`.
2022-11-20 20:35:40 +01:00
Ralf Jung
644a5a34dd enable fuzzy_provenance_casts lint in liballoc 2022-11-20 19:12:18 +01:00
Tshepang Mbambo
bebe5db517 replace unusual grammar 2022-11-20 17:28:34 +02:00
Markus Everling
a1bf25e2bd Update VecDeque implementation 2022-11-20 15:21:16 +01:00
bors
e07425d55b Auto merge of #98914 - fee1-dead-contrib:min-deref-patterns, r=compiler-errors
Minimal implementation of implicit deref patterns for Strings

cc `@compiler-errors` `@BoxyUwU` https://github.com/rust-lang/lang-team/issues/88 #87121

~~I forgot to add a feature gate, will do so in a minute~~ Done
2022-11-20 07:16:42 +00:00
Yuki Okushi
785237d392
Rollup merge of #104435 - scottmcm:iter-repeat-n, r=thomcc
`VecDeque::resize` should re-use the buffer in the passed-in element

Today it always copies it for *every* appended element, but one of those clones is avoidable.

This adds `iter::repeat_n` (https://github.com/rust-lang/rust/issues/104434) as the primitive needed to do this.  If this PR is acceptable, I'll also use this in `Vec` rather than its custom `ExtendElement` type & infrastructure that is harder to share between multiple different containers:

101e1822c3/library/alloc/src/vec/mod.rs (L2479-L2492)
2022-11-20 13:15:59 +09:00
Yuki Okushi
e69b84204a
Rollup merge of #104112 - yancyribbens:add-copy-to-repeat-description, r=JohnTitor
rustdoc: Add copy to the description of repeat

Small nit, but it's more clear to say `copy` here instead of defining `repeat` in terms of itself.
2022-11-20 13:15:58 +09:00
Zachary S
734f724472 Change undefined-behavior doctests from ignore to no_run. 2022-11-18 12:50:41 -06:00
zachs18
f542b068f2 Apply suggestions from code review
Fix spelling error.
2022-11-18 12:50:41 -06:00
Zachary S
8c38cb7709 Add examples to show when {Arc,Rc}::get_mut_unchecked is disallowed. 2022-11-18 12:50:41 -06:00
Zachary S
96650fc714 Clarify and restrict when {Arc,Rc}::get_mut_unchecked is allowed. 2022-11-18 12:50:41 -06:00
clubby789
27019f10ae Remove Vec/Rc storage reuse opt 2022-11-18 10:39:50 +00:00
Deadbeef
64a17a09a8 Rm diagnostic item, use lang item 2022-11-18 06:16:20 +00:00
Deadbeef
b2cb42d6a7 Minimal implementation of implicit deref patterns 2022-11-17 12:46:43 +00:00
bors
36db030a7c Auto merge of #104205 - clubby789:grow-rc, r=thomcc
Attempt to reuse `Vec<T>` backing storage for `Rc/Arc<[T]>`

If a `Vec<T>` has sufficient capacity to store the inner `RcBox<[T]>`, we can just reuse the existing allocation and shift the elements up, instead of making a new allocation.
2022-11-17 10:48:22 +00:00
The 8472
c37e8fae57 generalize str.contains() tests to a range of haystack sizes
The Big-O is cubic, but this is only called with ~70 chars so it's still fast enough
2022-11-15 18:30:07 +01:00
Scott McMurray
d62b903892 VecDeque::resize should re-use the buffer in the passed-in element
Today it always copies it for *every* appended element, but one of those clones is avoidable.
2022-11-15 00:53:26 -08:00
The 8472
467b299e53 update str.contains benchmarks 2022-11-14 23:03:16 +01:00
The 8472
4844e5162c black_box test strings in str.contains(str) benchmarks 2022-11-14 23:01:25 +01:00
yancy
f4ffdbfaad rustdoc: Add copy to the description of repeat 2022-11-14 15:21:02 +01:00
clubby789
8424c24837 Add Vec storage optimization to Arc and add tests 2022-11-14 02:30:18 +00:00
clubby789
1c813c4d11 Reuse Vec<T> backing storage for Rc<[T]>
Co-authored-by: joboet <jonas.boettiger@icloud.com>
2022-11-14 01:15:18 +00:00
bors
338cfd3cce Auto merge of #103858 - Mark-Simulacrum:bump-bootstrap, r=pietroalbini
Bump bootstrap compiler to 1.66

This PR:

- Bumps version placeholders to release
- Bumps to latest beta
- cfg-steps code

r? `@pietroalbini`
2022-11-14 00:07:19 +00:00
Guillaume Gomez
53b6a894ca
Rollup merge of #104097 - RalfJung:miri-alloc-benches, r=thomcc
run alloc benchmarks in Miri and fix UB

Miri since recently has a "fake monotonic clock" that works even with isolation. Its measurements are not very meaningful but it means we can run these benches and check them for UB.

And that's a good thing since there was UB here: fixes https://github.com/rust-lang/rust/issues/104096.

r? ``@thomcc``
2022-11-08 20:40:50 +01:00
Guillaume Gomez
afaba1997d
Rollup merge of #104093 - RalfJung:test-sizes, r=thomcc
disable btree size tests on Miri

Seems fine not to run these in Miri, they can't have UB anyway. And this lets us do layout randomization in Miri.

r? ``@thomcc``
2022-11-08 20:40:49 +01:00
Ralf Jung
29d451ccb3 fmt 2022-11-07 15:24:49 +01:00
Dylan DPC
81b8db2675
Rollup merge of #104090 - wanghaha-dev:master, r=Dylan-DPC
Modify comment syntax error

Modify comment syntax error
2022-11-07 18:35:26 +05:30
Ralf Jung
780952f922 run alloc benchmarks in Miri and fix UB 2022-11-07 10:34:04 +01:00
Ralf Jung
17044c1d00 disable btree size tests on Miri 2022-11-07 09:29:14 +01:00
wanghaha-dev
009f80b987 Modify comment syntax error 2022-11-07 14:33:33 +08:00
Yuki Okushi
57daec5989
Rollup merge of #104056 - ripytide:patch-1, r=Mark-Simulacrum
Vec: IntoIterator signature consistency

Also makes the code dryer.
2022-11-07 09:46:26 +09:00
Mark Rousskov
40290505fb cfg-step code 2022-11-06 17:21:21 -05:00
Mark Rousskov
455a7bc685 Bump version placeholders to release 2022-11-06 17:11:02 -05:00
ripytide
743726e352
Vec: IntoIterator signature consistency
Also makes the code dryer.
2022-11-06 15:25:00 +00:00
Anett Seeker
3b8b0ac62a Fix unused_must_use warning for Box::from_raw 2022-11-05 21:52:18 +01:00
Michael Goulet
2786acce98 Enforce Tuple trait on Fn traits 2022-11-05 17:34:47 +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
Dylan DPC
68db106366
Rollup merge of #103807 - H4x5:string-extend-from-within-tracking-issue, r=Dylan-DPC
Add tracking issue for `string_extend_from_within`

Tracking issue: #103806

The original PR didn't create a tracking issue.
2022-11-02 22:32:04 +05:30
Amanieu d'Antras
56074b5231 Rewrite implementation of #[alloc_error_handler]
The new implementation doesn't use weak lang items and instead changes
`#[alloc_error_handler]` to an attribute macro just like
`#[global_allocator]`.

The attribute will generate the `__rg_oom` function which is called by
the compiler-generated `__rust_alloc_error_handler`. If no `__rg_oom`
function is defined in any crate then the compiler shim will call
`__rdl_oom` in the alloc crate which will simply panic.

This also fixes link errors with `-C link-dead-code` with
`default_alloc_error_handler`: `__rg_oom` was previously defined in the
alloc crate and would attempt to reference the `oom` lang item, even if
it didn't exist. This worked as long as `__rg_oom` was excluded from
linking since it was not called.

This is a prerequisite for the stabilization of
`default_alloc_error_handler` (#102318).
2022-10-31 16:32:57 +00:00
Sky
3e23d60a32
Add tracking issue for string_extend_from_within 2022-10-31 12:01:20 -04:00
Ralf Jung
99a74afa5f ptr::eq: clarify that comparing dyn Trait is fragile 2022-10-26 11:15:14 +02:00
Nixon Enraght-Moony
674cd6125d Clairify Vec::capacity docs
Fixes #103326
2022-10-24 15:01:58 +01:00
Yuki Okushi
fbb3650c89
Rollup merge of #99578 - steffahn:remove_redundant_bound, r=thomcc
Remove redundant lifetime bound from `impl Borrow for Cow`

The lifetime bound `B::Owned: 'a` is redundant and doesn't make a difference,
because `Cow<'a, B>` comes with an implicit `B: 'a`, and associated types
will outlive lifetimes outlived by the `Self` type (and all the trait's
generic parameters, of which there are none in this case), so the implicit `B: 'a`
implies `B::Owned: 'a` anyway.

The explicit lifetime bound here does however [end up in documentation](https://doc.rust-lang.org/std/borrow/enum.Cow.html#impl-Borrow%3CB%3E),
and that's confusing in my opinion, so let's remove it ^^

_(Documentation right now, compare to `AsRef`, too:)_
![Screenshot_20220722_014055](https://user-images.githubusercontent.com/3986214/180332665-424d0c05-afb3-40d8-a330-a57a2c9a494b.png)
2022-10-24 19:32:24 +09:00
Finn Bear
9f0503e4a6 Fix typo in docs of String::leak. 2022-10-22 12:26:47 -07:00
Dylan DPC
b22559f547
Rollup merge of #103346 - HeroicKatora:metadata_of_const_pointer_argument, r=dtolnay
Adjust argument type for mutable with_metadata_of (#75091)

The method takes two pointer arguments: one `self` supplying the pointer value, and a second pointer supplying the metadata.

The new parameter type more clearly reflects the actual requirements. The provenance of the metadata parameter is disregarded completely. Using a mutable pointer in the call site can be coerced to a const pointer while the reverse is not true.

In some cases, the current parameter type can thus lead to a very slightly confusing additional cast. [Example](cad93775eb).

```rust
// Manually taking an unsized object from a `ManuallyDrop` into another allocation.
let val: &core::mem::ManuallyDrop<T> = …;

let ptr = val as *const _ as *mut T;
let ptr = uninit.as_ptr().with_metadata_of(ptr);
```

This could then instead be simplified to:

```rust
// Manually taking an unsized object from a `ManuallyDrop` into another allocation.
let val: &core::mem::ManuallyDrop<T> = …;

let ptr = uninit.as_ptr().with_metadata_of(&**val);
```

Tracking issue: https://github.com/rust-lang/rust/issues/75091

``@dtolnay`` you're reviewed #95249, would you mind chiming in?
2022-10-22 16:28:09 +05:30
Dylan DPC
141478b40f
Rollup merge of #103280 - finnbear:impl_string_leak_2, r=joshtriplett
(#102929) Implement `String::leak` (attempt 2)

Implementation of `String::leak` (#102929)

ACP: https://github.com/rust-lang/libs-team/issues/109

Supersedes #102941 (see previous reviews there)

```@rustbot``` label +T-libs-api -T-libs
2022-10-22 16:28:08 +05:30
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
Andreas Molzer
e3606b2b02 Reduce mutability in std-use of with_metadata_of 2022-10-21 14:49:29 +02:00
Finn Bear
4f44d6253d Put fn in the right place. 2022-10-19 19:15:58 -07:00
Finn Bear
f81cd87eea Copy of #102941. 2022-10-19 19:07:45 -07:00
Dylan DPC
d056ea8828
Rollup merge of #103153 - ChrisDenton:leak-oom, r=m-ou-se
Allow `Vec::leak` when using `no_global_oom_handling`

As [the documentation notes](https://doc.rust-lang.org/std/vec/struct.Vec.html#method.leak), `Vec::leak` hasn't allocated since 1.57.

cc `@Ericson2314` in case I'm missing something.
2022-10-19 14:05:53 +05:30
Yuki Okushi
b411b8861c
Rollup merge of #103163 - SUPERCILEX:uninit-array-assume2, r=scottmcm
Remove all uses of array_assume_init

See https://github.com/rust-lang/rust/pull/103134#discussion_r997462733

r? `@scottmcm`
2022-10-18 21:21:32 +09:00
Alex Saveau
55d71c61b8
Remove all uses of array_assume_init
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
2022-10-17 13:03:54 -07:00
bors
06f049a355 Auto merge of #101837 - scottmcm:box-array-from-vec, r=m-ou-se
Add `Box<[T; N]>: TryFrom<Vec<T>>`

We have `[T; N]: TryFrom<Vec<T>>` (#76310) and `Box<[T; N]>: TryFrom<Box<[T]>>`, but not this combination.

`vec.into_boxed_slice().try_into()` isn't quite a replacement for this, as that'll reallocate unnecessarily in the error case.

**Insta-stable, so needs an FCP**

(I tried to make this work with `, A`, but that's disallowed because of `#[fundamental]` https://github.com/rust-lang/rust/issues/29635#issuecomment-1247598385)
2022-10-17 19:46:04 +00:00
Chris Denton
913393a0f7
Allow Vec::leak with no_global_oom_handling 2022-10-17 17:12:32 +01:00
philipp
4854e37dbc Documentation BTreeMap::append's behavior for already existing keys 2022-10-15 17:47:07 +02:00
bors
ee1c3b385b Auto merge of #102529 - colinba:master, r=joshtriplett
Detect and reject out-of-range integers in format string literals

Until now out-of-range integers in format string literals were silently ignored. They wrapped around to zero at usize::MAX, producing unexpected results.

When using debug builds of rustc, such integers in format string literals even cause an 'attempt to add with overflow' panic in rustc.

Fix this by producing an error diagnostic for integers in format string literals which do not fit into usize.

Fixes #102528
2022-10-14 13:41:40 +00:00
Rageking8
7122abaddf more dupe word typos 2022-10-14 12:57:56 +08:00
Ralf Jung
2b50cd1877 rename rustc_allocator_nounwind to rustc_nounwind 2022-10-11 22:47:31 +02:00
Matthias Krüger
cadb37a8c7
Rollup merge of #101727 - est31:stabilize_map_first_last, r=m-ou-se
Stabilize map_first_last

Stabilizes the following functions:

```Rust
impl<T> BTreeSet<T> {
    pub fn first(&self) -> Option<&T> where T: Ord;
    pub fn last(&self) -> Option<&T> where T: Ord;
    pub fn pop_first(&mut self) -> Option<T> where T: Ord;
    pub fn pop_last(&mut self) -> Option<T> where T: Ord;
}

impl<K, V> BTreeMap<K, V> {
    pub fn first_key_value(&self) -> Option<(&K, &V)> where K: Ord;
    pub fn last_key_value(&self) -> Option<(&K, &V)> where K: Ord;
    pub fn first_entry(&mut self) -> Option<OccupiedEntry<'_, K, V>> where K: Ord;
    pub fn last_entry(&mut self) -> Option<OccupiedEntry<'_, K, V>> where K: Ord;
    pub fn pop_first(&mut self) -> Option<(K, V)> where K: Ord;
    pub fn pop_last(&mut self) -> Option<(K, V)> where K: Ord;
}
```

Closes #62924

~~Blocked on the [FCP](https://github.com/rust-lang/rust/issues/62924#issuecomment-1179489929) finishing.~~ Edit: It finished!
2022-10-11 18:59:46 +02:00
bors
a6b7274a46 Auto merge of #102596 - scottmcm:option-bool-calloc, r=Mark-Simulacrum
Do the `calloc` optimization for `Option<bool>`

Inspired by <https://old.reddit.com/r/rust/comments/xtiqj8/why_is_this_functional_version_faster_than_my_for/iqqy37b/>.
2022-10-10 18:42:40 +00: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
Konrad Borowski
cef81dcd0a Fix handling of trailing bare CR in str::lines
Previously "bare\r" was split into ["bare"] even though the
documentation said that only LF and CRLF count as newlines.

This fix is a behavioural change, even though it brings the behaviour
into line with the documentation, and into line with that of
`std::io::BufRead::lines()`.

This is an alternative to #91051, which proposes to document rather
than fix the behaviour.

Fixes #94435.

Co-authored-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2022-10-06 16:05:38 +00:00
David Tolnay
4fdd0d9675
Fix overconstrained Send impls in btree internals 2022-10-05 12:16:32 -07:00
David Tolnay
fa863414fe
Add regression test for lifetimes in alloc internals autotraits
Currently pretty much all of the btree_map and btree_set ones fail, as
well as linked_list::DrainFilter.

    error: higher-ranked lifetime error
      --> library/alloc/tests/autotraits.rs:38:5
       |
    38 | /     require_send_sync(async {
    39 | |         let _v = None::<alloc::collections::btree_map::Iter<'_, &u32, &u32>>;
    40 | |         async {}.await;
    41 | |     });
       | |______^
       |
       = note: could not prove `impl Future<Output = ()>: Send`

    error: implementation of `Send` is not general enough
      --> library/alloc/tests/autotraits.rs:56:5
       |
    56 | /     require_send_sync(async {
    57 | |         let _v = None::<
    58 | |             alloc::collections::btree_map::DrainFilter<
    59 | |                 '_,
    ...  |
    65 | |         async {}.await;
    66 | |     });
       | |______^ implementation of `Send` is not general enough
       |
       = note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
       = note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`

    error: implementation of `Send` is not general enough
      --> library/alloc/tests/autotraits.rs:68:5
       |
    68 | /     require_send_sync(async {
    69 | |         let _v = None::<alloc::collections::btree_map::Entry<'_, &u32, &u32>>;
    70 | |         async {}.await;
    71 | |     });
       | |______^ implementation of `Send` is not general enough
       |
       = note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
       = note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`

    error: higher-ranked lifetime error
      --> library/alloc/tests/autotraits.rs:88:5
       |
    88 | /     require_send_sync(async {
    89 | |         let _v = None::<alloc::collections::btree_map::Iter<'_, &u32, &u32>>;
    90 | |         async {}.await;
    91 | |     });
       | |______^
       |
       = note: could not prove `impl Future<Output = ()>: Send`

    error: implementation of `Send` is not general enough
      --> library/alloc/tests/autotraits.rs:93:5
       |
    93 | /     require_send_sync(async {
    94 | |         let _v = None::<alloc::collections::btree_map::IterMut<'_, &u32, &u32>>;
    95 | |         async {}.await;
    96 | |     });
       | |______^ implementation of `Send` is not general enough
       |
       = note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
       = note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`

    error: higher-ranked lifetime error
       --> library/alloc/tests/autotraits.rs:98:5
        |
    98  | /     require_send_sync(async {
    99  | |         let _v = None::<alloc::collections::btree_map::Keys<'_, &u32, &u32>>;
    100 | |         async {}.await;
    101 | |     });
        | |______^
        |
        = note: could not prove `impl Future<Output = ()>: Send`

    error: implementation of `Send` is not general enough
       --> library/alloc/tests/autotraits.rs:103:5
        |
    103 | /     require_send_sync(async {
    104 | |         let _v = None::<alloc::collections::btree_map::OccupiedEntry<'_, &u32, &u32>>;
    105 | |         async {}.await;
    106 | |     });
        | |______^ implementation of `Send` is not general enough
        |
        = note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
        = note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`

    error: implementation of `Send` is not general enough
       --> library/alloc/tests/autotraits.rs:108:5
        |
    108 | /     require_send_sync(async {
    109 | |         let _v = None::<alloc::collections::btree_map::OccupiedError<'_, &u32, &u32>>;
    110 | |         async {}.await;
    111 | |     });
        | |______^ implementation of `Send` is not general enough
        |
        = note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
        = note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`

    error: higher-ranked lifetime error
       --> library/alloc/tests/autotraits.rs:113:5
        |
    113 | /     require_send_sync(async {
    114 | |         let _v = None::<alloc::collections::btree_map::Range<'_, &u32, &u32>>;
    115 | |         async {}.await;
    116 | |     });
        | |______^
        |
        = note: could not prove `impl Future<Output = ()>: Send`

    error: implementation of `Send` is not general enough
       --> library/alloc/tests/autotraits.rs:118:5
        |
    118 | /     require_send_sync(async {
    119 | |         let _v = None::<alloc::collections::btree_map::RangeMut<'_, &u32, &u32>>;
    120 | |         async {}.await;
    121 | |     });
        | |______^ implementation of `Send` is not general enough
        |
        = note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
        = note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`

    error: implementation of `Send` is not general enough
       --> library/alloc/tests/autotraits.rs:123:5
        |
    123 | /     require_send_sync(async {
    124 | |         let _v = None::<alloc::collections::btree_map::VacantEntry<'_, &u32, &u32>>;
    125 | |         async {}.await;
    126 | |     });
        | |______^ implementation of `Send` is not general enough
        |
        = note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
        = note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`

    error: higher-ranked lifetime error
       --> library/alloc/tests/autotraits.rs:128:5
        |
    128 | /     require_send_sync(async {
    129 | |         let _v = None::<alloc::collections::btree_map::Values<'_, &u32, &u32>>;
    130 | |         async {}.await;
    131 | |     });
        | |______^
        |
        = note: could not prove `impl Future<Output = ()>: Send`

    error: implementation of `Send` is not general enough
       --> library/alloc/tests/autotraits.rs:133:5
        |
    133 | /     require_send_sync(async {
    134 | |         let _v = None::<alloc::collections::btree_map::ValuesMut<'_, &u32, &u32>>;
    135 | |         async {}.await;
    136 | |     });
        | |______^ implementation of `Send` is not general enough
        |
        = note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
        = note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`

    error: higher-ranked lifetime error
       --> library/alloc/tests/autotraits.rs:146:5
        |
    146 | /     require_send_sync(async {
    147 | |         let _v = None::<alloc::collections::btree_set::Difference<'_, &u32>>;
    148 | |         async {}.await;
    149 | |     });
        | |______^
        |
        = note: could not prove `impl Future<Output = ()>: Send`

    error: implementation of `Send` is not general enough
       --> library/alloc/tests/autotraits.rs:151:5
        |
    151 | /     require_send_sync(async {
    152 | |         let _v = None::<alloc::collections::btree_set::DrainFilter<'_, &u32, fn(&&u32) -> bool>>;
    153 | |         async {}.await;
    154 | |     });
        | |______^ implementation of `Send` is not general enough
        |
        = note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
        = note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`

    error: higher-ranked lifetime error
       --> library/alloc/tests/autotraits.rs:156:5
        |
    156 | /     require_send_sync(async {
    157 | |         let _v = None::<alloc::collections::btree_set::Intersection<'_, &u32>>;
    158 | |         async {}.await;
    159 | |     });
        | |______^
        |
        = note: could not prove `impl Future<Output = ()>: Send`

    error: higher-ranked lifetime error
       --> library/alloc/tests/autotraits.rs:166:5
        |
    166 | /     require_send_sync(async {
    167 | |         let _v = None::<alloc::collections::btree_set::Iter<'_, &u32>>;
    168 | |         async {}.await;
    169 | |     });
        | |______^
        |
        = note: could not prove `impl Future<Output = ()>: Send`

    error: higher-ranked lifetime error
       --> library/alloc/tests/autotraits.rs:171:5
        |
    171 | /     require_send_sync(async {
    172 | |         let _v = None::<alloc::collections::btree_set::Range<'_, &u32>>;
    173 | |         async {}.await;
    174 | |     });
        | |______^
        |
        = note: could not prove `impl Future<Output = ()>: Send`

    error: higher-ranked lifetime error
       --> library/alloc/tests/autotraits.rs:176:5
        |
    176 | /     require_send_sync(async {
    177 | |         let _v = None::<alloc::collections::btree_set::SymmetricDifference<'_, &u32>>;
    178 | |         async {}.await;
    179 | |     });
        | |______^
        |
        = note: could not prove `impl Future<Output = ()>: Send`

    error: higher-ranked lifetime error
       --> library/alloc/tests/autotraits.rs:181:5
        |
    181 | /     require_send_sync(async {
    182 | |         let _v = None::<alloc::collections::btree_set::Union<'_, &u32>>;
    183 | |         async {}.await;
    184 | |     });
        | |______^
        |
        = note: could not prove `impl Future<Output = ()>: Send`

    error: future cannot be sent between threads safely
       --> library/alloc/tests/autotraits.rs:243:23
        |
    243 |       require_send_sync(async {
        |  _______________________^
    244 | |         let _v =
    245 | |             None::<alloc::collections::linked_list::DrainFilter<'_, &u32, fn(&mut &u32) -> bool>>;
    246 | |         async {}.await;
    247 | |     });
        | |_____^ future created by async block is not `Send`
        |
        = help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `NonNull<std::collections::linked_list::Node<&u32>>`
    note: future is not `Send` as this value is used across an await
       --> library/alloc/tests/autotraits.rs:246:17
        |
    244 |         let _v =
        |             -- has type `Option<std::collections::linked_list::DrainFilter<'_, &u32, for<'a, 'b> fn(&'a mut &'b u32) -> bool>>` which is not `Send`
    245 |             None::<alloc::collections::linked_list::DrainFilter<'_, &u32, fn(&mut &u32) -> bool>>;
    246 |         async {}.await;
        |                 ^^^^^^ await occurs here, with `_v` maybe used later
    247 |     });
        |     - `_v` is later dropped here
    note: required by a bound in `require_send_sync`
       --> library/alloc/tests/autotraits.rs:3:25
        |
    3   | fn require_send_sync<T: Send + Sync>(_: T) {}
        |                         ^^^^ required by this bound in `require_send_sync`

    error: future cannot be shared between threads safely
       --> library/alloc/tests/autotraits.rs:243:23
        |
    243 |       require_send_sync(async {
        |  _______________________^
    244 | |         let _v =
    245 | |             None::<alloc::collections::linked_list::DrainFilter<'_, &u32, fn(&mut &u32) -> bool>>;
    246 | |         async {}.await;
    247 | |     });
        | |_____^ future created by async block is not `Sync`
        |
        = help: within `impl Future<Output = ()>`, the trait `Sync` is not implemented for `NonNull<std::collections::linked_list::Node<&u32>>`
    note: future is not `Sync` as this value is used across an await
       --> library/alloc/tests/autotraits.rs:246:17
        |
    244 |         let _v =
        |             -- has type `Option<std::collections::linked_list::DrainFilter<'_, &u32, for<'a, 'b> fn(&'a mut &'b u32) -> bool>>` which is not `Sync`
    245 |             None::<alloc::collections::linked_list::DrainFilter<'_, &u32, fn(&mut &u32) -> bool>>;
    246 |         async {}.await;
        |                 ^^^^^^ await occurs here, with `_v` maybe used later
    247 |     });
        |     - `_v` is later dropped here
    note: required by a bound in `require_send_sync`
       --> library/alloc/tests/autotraits.rs:3:32
        |
    3   | fn require_send_sync<T: Send + Sync>(_: T) {}
        |                                ^^^^ required by this bound in `require_send_sync`
2022-10-05 12:15:17 -07: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
Matthias Krüger
098e8b7357
Rollup merge of #98218 - kpreid:nostdarc, r=joshtriplett
Document the conditional existence of `alloc::sync` and `alloc::task`.

`alloc` declares

```rust
#[cfg(target_has_atomic = "ptr")]
pub mod sync;
```

but there is no public documentation of this condition. This PR fixes that, so that users of `alloc` can understand how to make their code compile everywhere `alloc` does, if they are writing a library with impls for `Arc`.

The wording is copied from `std::sync::atomic::AtomicPtr`, with additional advice on how to `#[cfg]` for it.

I feel quite uncertain about whether the paragraph I added to `Arc`'s documentation should actually be there, as it is a distraction for anyone using `std`. On the other hand, maybe more reminders that no_std exists would benefit the ecosystem.

Note: `target_has_atomic` is [stabilized](https://github.com/rust-lang/rust/issues/32976) but [not yet documented in the reference](https://github.com/rust-lang/reference/pull/1171).
2022-10-03 20:58:53 +02:00
Giacomo Stevanato
1750c7bdd3 Clarify documentation 2022-10-03 20:23:54 +02:00
Scott McMurray
31cd0aa823 Do the calloc optimization for Option<bool>
Inspired by <https://old.reddit.com/r/rust/comments/xtiqj8/why_is_this_functional_version_faster_than_my_for/iqqy37b/>.
2022-10-02 12:26:58 -07:00
Dylan DPC
890a327c86
Rollup merge of #102556 - WaffleLapkin:implied_by_btree_new, r=Mark-Simulacrum
Make `feature(const_btree_len)` implied by `feature(const_btree_new)`

...this should fix code that used the old feature that was changed in #102197

cc ```@davidtwco``` it seems like tidy doesn't check `implied_by`, should it?
2022-10-02 20:42:22 +05:30
Dylan DPC
ed9740846b
Rollup merge of #102098 - xfix:weak-upgrade-fetch-update, r=Mark-Simulacrum
Use fetch_update in sync::Weak::upgrade

Using `fetch_update` makes it more clear that it's CAS loop then manually implementing one.
2022-10-02 20:42:21 +05:30
Maybe Waffle
da78c1fd43 Make feature(const_btree_len) implied by feature(const_btree_new) 2022-10-01 22:40:04 +00:00
Colin Baumgarten
b9e85bf60a Detect and reject out-of-range integers in format string literals
Until now out-of-range integers in format string literals
were silently ignored. They wrapped around to zero at
usize::MAX, producing unexpected results.

When using debug builds of rustc, such integers in format string
literals even cause an 'attempt to add with overflow' panic in
rustc.

Fix this by producing an error diagnostic for integers in format
string literals which do not fit into usize.

Fixes #102528
2022-10-01 01:05:01 +02:00
est31
2c72ea7748 Stabilize map_first_last 2022-09-30 17:00:07 +02:00