nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-10-31 22:41:50 +00:00
Code Issues Packages Projects Releases Wiki Activity
216,434 Commits 7 Branches 139 Tags 1.9 GiB
e99e05d135
Commit Graph

1996 Commits

Author SHA1 Message Date
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
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
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
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
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
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