nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-30 02:33:55 +00:00
Code Issues Packages Projects Releases Wiki Activity
218,565 Commits 7 Branches 140 Tags 1.8 GiB
b69de64202
Commit Graph

2023 Commits

Author SHA1 Message Date
Dylan DPC
093a53f134
Rollup merge of #108462 - pommicket:fix-vecdeque-zst-overflow, r=Amanieu 
Fix `VecDeque::append` capacity overflow for ZSTs

Fixes #108454.
 2023-03-01 23:40:20 +05:30
bors
64165aac68 Auto merge of #108476 - saethlin:remove-library-rustc-box, r=thomcc 
Remove or document uses of #[rustc_box] in library

r? `@thomcc`

Only one of these uses is tested for in the rustc-perf benchmark suite. The impact there on compile time is somewhat dramatic, but I am inclined to make this change as a simplification to the library and wait for people to complain if it explodes their compilation time. I think in the absence of data or reports from users about what code paths really matter, if we are optimizing for compilation time, it's hard to argue against using `#[rustc_box]` everywhere we currently call `Box::new`.
 2023-03-01 09:13:23 +00:00
Ben Kimock
5448123a11 Remove or justify use of #[rustc_box] 2023-02-27 20:54:55 -05:00
Markus Everling
4a4f43e4e9 Disambiguate comments 2023-02-26 03:13:56 +01:00
Markus Everling
9e22516877 Fix VecDeque::shrink_to and add tests. 
This adds both a test specific to #108453 as well as an exhaustive test
that goes through all possible combinations of head index, length and target capacity
for a deque with capacity 16.
 2023-02-26 03:13:44 +01:00
pommicket
12f959ba39 Add test for VecDeque::append ZST capacity overflow 2023-02-25 13:50:56 -05:00
pommicket
379b18bb0a Use checked_add in VecDeque::append for ZSTs to avoid overflow 2023-02-25 11:05:21 -05:00
Matthias Krüger
7c562ee5a6
Rollup merge of #108407 - notriddle:notriddle/vec-get-mut, r=thomcc 
docs: use intra-doc links for `Vec::get(_mut)`

Now that #63351 is fixed, there's no reason not to.

CC #75672
 2023-02-25 11:31:33 +01:00
Dylan DPC
b3657f92d1
Rollup merge of #106918 - dtolnay:heapretain, r=the8472 
Rebuild BinaryHeap on unwind from retain

This closes the hole identified in https://github.com/rust-lang/rust/issues/71503#issuecomment-1383251315 which had made it possible for the caller to end up with a heap in invalid state. As of #105851, heaps in invalid state are not supposed to exist.
 2023-02-24 12:02:41 +05:30
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
bors
4507fdaaa2 Auto merge of #106241 - Sp00ph:vec_deque_iter_methods, r=the8472 
Implement more methods for `vec_deque::IntoIter`

This implements a couple `Iterator` methods on `vec_deque::IntoIter` (`(try_)fold`, `(try_)rfold` `advance_(back_)by`, `next_chunk`, `count` and `last`) to allow these to be more efficient than their default implementations, also allowing many other `Iterator` methods that use these under the hood to take advantage of these manual implementations. `vec::IntoIter` has similar implementations for many of these methods. This PR does not yet implement `TrustedRandomAccess` and friends, as I'm not very familiar with the required safety guarantees.

r? `@the8472` (since you also took over my last PR)
 2023-02-18 20:12:35 +00:00
bors
adb4bfd25d Auto merge of #105671 - lukas-code:depreciate-char, r=scottmcm 
Use associated items of `char` instead of freestanding items in `core::char`

The associated functions and constants on `char` have been stable since 1.52 and the freestanding items have soft-deprecated since 1.62 (https://github.com/rust-lang/rust/pull/95566). This PR ~~marks them as "deprecated in future", similar to the integer and floating point modules (`core::{i32, f32}` etc)~~ replaces all uses of `core::char::*` with `char::*` to prepare for future deprecation of `core::char::*`.
 2023-02-12 11:09:06 +00:00
bors
d094016128 Auto merge of #106677 - tbu-:pr_less_doc_hidden_pub, r=scottmcm 
Remove a couple of `#[doc(hidden)] pub fn` and their `#[feature]` gates
 2023-02-11 23:57:05 +00:00
bors
8dabf5da9e Auto merge of #107167 - the8472:rawvec-simpler-layout, r=thomcc 
simplify layout calculations in rawvec

The use of `Layout::array` was introduced in #83706 which lead to a [perf regression](https://github.com/rust-lang/rust/pull/83706#issuecomment-1048377719).

This PR basically reverts that change since rust currently only supports stride == size types, but to be on the safe side it leaves a const-assert there to make sure this gets caught if those assumptions ever change.
 2023-02-11 15:08:30 +00:00
Tobias Bucher
77c85e9cba Remove a couple of #[doc(hidden)] pub fn and their #[feature] gates 2023-02-10 08:06:35 +01:00
Michael Goulet
aee4570adf
Rollup merge of #107429 - tgross35:from-bytes-until-null-stabilization, r=dtolnay 
Stabilize feature `cstr_from_bytes_until_nul`

This PR seeks to stabilize `cstr_from_bytes_until_nul`.

Partially addresses #95027

This function has only been on nightly for about 10 months, but I think it is simple enough that there isn't harm discussing stabilization. It has also had at least a handful of mentions on both the user forum and the discord, so it seems like it's already in use or at least known.

This needs FCP still.

Comment on potential discussion points:
- eventual conversion of `CStr` to be a single thin pointer: this function will still be useful to provide a safe way to create a `CStr` after this change.
- should this return a length too, to address concerns about the `CStr` change? I don't see it as being particularly useful, and it seems less ergonomic (i.e. returning `Result<(&CStr, usize), FromBytesUntilNulError>`). I think users that also need this length without the additional `strlen` call are likely better off using a combination of other methods, but this is up for discussion
- `CString::from_vec_until_nul`: this is also useful, but it doesn't even have a nightly implementation merged yet. I propose feature gating that separately, as opposed to blocking this `CStr` implementation on that

Possible alternatives:

A user can use `from_bytes_with_nul` on a slice up to `my_slice[..my_slice.iter().find(|c| c == 0).unwrap()]`. However; that is significantly less ergonomic, and is a bit more work for the compiler to optimize compared the direct `memchr` call that this wraps.

## New stable API

```rs
// both in core::ffi

pub struct FromBytesUntilNulError(());

impl CStr {
    pub const fn from_bytes_until_nul(
        bytes: &[u8]
    ) -> Result<&CStr, FromBytesUntilNulError>
}
```

cc ```@ericseppanen``` original author, ```@Mark-Simulacrum``` original reviewer, ```@m-ou-se``` brought up some issues on the thin pointer CStr

```@rustbot``` modify labels: +T-libs-api +needs-fcp
 2023-02-08 20:01:24 -08:00
Matthias Krüger
562581c2db
Rollup merge of #105641 - Amanieu:btree_cursor, r=m-ou-se 
Implement cursors for BTreeMap

See the ACP for an overview of the API: https://github.com/rust-lang/libs-team/issues/141

The implementation is split into 2 commits:
- The first changes the internal insertion functions to return a handle to the newly inserted element. The lifetimes involved are a bit hairy since we need a mutable handle to both the `BTreeMap` itself (which holds the root) and the nodes allocated in memory. I have tested that this passes the standard library testsuite under miri.
- The second commit implements the cursor API itself. This is more straightforward to follow but still involves some unsafe code to deal with simultaneous mutable borrows of the tree root and the node that is currently being iterated.
 2023-02-08 18:32:41 +01:00
Danilo Bargen
4f36673e15 Docs: Fix format of headings in String::reserve 2023-02-07 21:32:28 +01:00
Trevor Gross
83b05ef0ee Stabilize feature 'cstr_from_bytes_until_nul' 2023-02-01 02:14:07 -05:00
Amanieu d'Antras
36831b3ccb BTreeMap: Add Cursor and CursorMut 2023-02-01 00:16:15 +00:00
Amanieu d'Antras
eb70c82d29 BTreeMap: Change internal insert function to return a handle 
This is a prerequisite for cursor support for `BTreeMap`.
 2023-02-01 00:08:59 +00:00
bors
dc1d9d50fb Auto merge of #107297 - Mark-Simulacrum:bump-bootstrap, r=pietroalbini 
Bump bootstrap compiler to 1.68

This also changes our stage0.json to include the rustc component for the rustfmt pinned nightly toolchain, which is currently necessary due to rustfmt dynamically linking to that toolchain's librustc_driver and libstd.

r? `@pietroalbini`
 2023-01-31 19:24:29 +00:00
Matthias Krüger
b3b9383f8d
Rollup merge of #107424 - bpeel:clone-into-from-share-code, r=scottmcm 
Make Vec::clone_from and slice::clone_into share the same code

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` method only works for vecs with the default allocator so it would have the wrong type to clone into `Vec<T, A>`.

Later on in 361398009b the code for the two methods diverged because the `Vec::clone_from` version gained a specialization to optimize the case when T is Copy. In order to reduce code duplication and make them both be able to take advantage of this specialization, this PR moves the specialization into the slice module and makes vec use it again.
 2023-01-30 17:50:10 +01:00
Dylan DPC
f01b8f5cf4
Rollup merge of #107452 - y21:get-mut-unchecked-typo, r=Mark-Simulacrum 
Fix typo in `{Rc, Arc}::get_mut_unchecked` docs

Just a correction in the documentation of `{Rc, Arc}::get_mut_unchecked`.
 2023-01-30 15:11:46 +05:30
Dylan DPC
28340bab88
Rollup merge of #101569 - m-ou-se:alloc-no-rexport-argumentv1, r=thomcc 
Don't re-export private/unstable ArgumentV1 from `alloc`.

The `alloc::fmt::ArgumentV1` re-export was marked as `#[stable]` even though the original `core::fmt::ArgumentV1` is `#[unstable]` (and `#[doc(hidden)]`).

(It wasn't usable though:

```
error[E0658]: use of unstable library feature 'fmt_internals': internal to format_args!
 --> src/main.rs:4:12
  |
4 |     let _: alloc::fmt::ArgumentV1 = todo!();
  |            ^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: add `#![feature(fmt_internals)]` to the crate attributes to enable
```
)

Part of #99012
 2023-01-30 15:11:44 +05:30
Mara Bos
67bb7ba3ea Don't re-export private/unstable ArgumentV1 from alloc. 2023-01-29 20:15:02 +01:00
y21
61b18b58ab fix typo in {Rc, Arc}::get_mut_unchecked docs 2023-01-29 20:11:36 +01: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
Neil Roberts
ba80c662f4 slice: Add a specialization for clone_into when T is Copy 
The implementation for the ToOwned::clone_into method on [T] is a copy
of the code for vec::clone_from. In 361398009b the code for
vec::clone_from gained a specialization for when T is Copy. This commit
copies that specialization over to the clone_into implementation.
 2023-01-28 20:37:01 +01:00
Gary Guo
66f3ab90a1 Reintroduce multiple_supertrait_upcastable lint 2023-01-28 15:08:07 +00:00
Mark Rousskov
3653254f91 Set version placeholders to 1.68 2023-01-25 09:44:29 -05:00
Yuki Okushi
8709c395a6
Rollup merge of #107109 - est31:thin_box_link, r=Mark-Simulacrum 
ThinBox: Add intra-doc-links for Metadata
 2023-01-23 19:30:00 +09:00
Dylan DPC
28081a6aa6
Rollup merge of #106854 - steffahn:drop_linear_arc_rebased, r=Mark-Simulacrum 
Add `Arc::into_inner` for safely discarding `Arc`s without calling the destructor on the inner type.

ACP: rust-lang/libs-team#162

Reviving #79665.

I want to get this merged this time; this does not contain changes (apart from very minor changes in comments/docs).

See #79665 for further description of the PR. The only “unresolved” points that led to that PR being closed, AFAICT, were

* The desire to also implement a `Rc::into_inner` function
  * however, this can very well also happen as a subsequent PR
* Possible need for further discussion on the naming “`into_inner`” (?)
  * `into_inner` seems fine to me; also, this PR introduces unstable API, and names can be changed later, too
* ~~I don't know if a tracking issue for the feature flag is supposed to be opened before or after this PR gets merged (if *before*, then I can add the issue number to the `#[unstable…]` attribute)~~ There is a [tracking issue](https://github.com/rust-lang/rust/issues/106894) now.

I say “unresolved” in quotation marks because from my point of view, if reviewers agree, the PR can be merged immediately and as-is :-)
 2023-01-23 11:52:04 +05:30
The 8472
6fcf1758fe simplify layout calculations in rawvec 2023-01-22 22:13:17 +01:00
Frank Steffahn
33696fa9ca Add Arc::into_inner for safely discarding Arcs without calling the destructor on the inner type. 
Mainly rebased and squashed from PR rust-lang/rust#79665,
furthermore includes minor changes in comments.
 2023-01-22 01:43:25 +09:00
Michael Goulet
68b390ae2a
Rollup merge of #104672 - Voultapher:unify-sort-modules, r=thomcc 
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`.

This is in preparation of #100856 and #104116. It only moves code, it *doesn't* change any of the sort related logic. This unlocks the ability to share `insert_head`, `insert_tail`, `swap_if_less` `merge` and more.

Tagging ````@Mark-Simulacrum```` I hope this allows progress on #100856, by moving `merge_sort` here I hope future changes will be easier to review.
 2023-01-20 21:33:21 -05:00
est31
4127988317 ThinBox: Add intra-doc-links for Metadata 2023-01-20 08:07:45 +01:00
bors
705a96d39b Auto merge of #106989 - clubby789:is-zero-num, r=scottmcm 
Implement `alloc::vec::IsZero` for `Option<$NUM>` types

Fixes #106911

Mirrors the `NonZero$NUM` implementations with an additional `assert_zero_valid`.
`None::<i32>` doesn't stricly satisfy `IsZero` but for the purpose of allocating we can produce more efficient codegen.
 2023-01-19 08:04:26 +00:00
clubby789
50e9f2e6e8 Update IsZero documentation 2023-01-18 15:48:53 +00:00
clubby789
b94a29a25f Implement alloc::vec::IsZero for Option<$NUM> types 2023-01-18 15:15:15 +00:00
Dylan DPC
1ff4a1259d
Rollup merge of #106950 - the8472:fix-splice-miri, r=cuviper 
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.

Fixes miri test failures.
Fixes https://github.com/rust-lang/miri/issues/2759
 2023-01-18 15:55:38 +05:30
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