Commit Graph

16567 Commits

Author SHA1 Message Date
Matthias Krüger
cb5bb13ea9
Rollup merge of #131256 - RalfJung:f16-f128-const, r=ibraheemdev
move f16/f128 const fn under f16/f128 feature gate

The `*_const` features were added to work around https://github.com/rust-lang/rust/issues/129656, which should not be needed any more.
2024-10-05 13:15:58 +02:00
Matthias Krüger
92beb42f64
Rollup merge of #131094 - joboet:lazy_once_box, r=ibraheemdev
std: replace `LazyBox` with `OnceBox`

This PR replaces the `LazyBox` wrapper used to allocate the pthread primitives with `OnceBox`, which has a more familiar API mirroring that of `OnceLock`. This cleans up the code in preparation for larger changes like #128184 (from which this PR was split) and allows some neat optimizations, like avoid an acquire-load of the allocation pointer in `Mutex::unlock`, where the initialization of the allocation must have already been observed.

Additionally, I've gotten rid of the TEEOS `Condvar` code, it's just a duplicate of the pthread one anyway and I didn't want to repeat myself.
2024-10-05 13:15:57 +02:00
Ralf Jung
0cd0f7ceef move f16/f128 const fn under f16/f128 feature gate 2024-10-05 10:13:18 +02:00
onestacked
d0e6758677 Stabilize const_slice_split_at_mut and const_slice_first_last_chunk 2024-10-05 09:52:13 +02:00
Jubilee
3078b23bbf
Rollup merge of #131267 - okaneco:bufread_skip_until, r=tgross35
Stabilize `BufRead::skip_until`

FCP completed https://github.com/rust-lang/rust/issues/111735#issuecomment-2393893069

Closes #111735
2024-10-04 19:19:26 -07:00
Jubilee
5bad4e9cae
Rollup merge of #131105 - slanterns:literal_c_str, r=petrochenkov
update `Literal`'s intro

Just something missd when adding c_str to it.
2024-10-04 19:19:24 -07:00
Jubilee
49c6d78117
Rollup merge of #130403 - eduardosm:stabilize-const_slice_from_raw_parts_mut, r=workingjubilee
Stabilize `const_slice_from_raw_parts_mut`

Stabilizes https://github.com/rust-lang/rust/issues/67456, since https://github.com/rust-lang/rust/issues/57349 has been stabilized.

Stabilized const API:
```rust
// core::ptr
pub const fn slice_from_raw_parts_mut<T>(data: *mut T, len: usize) -> *mut [T];

// core::slice
pub const unsafe fn from_raw_parts_mut<'a, T>(data: *mut T, len: usize) -> &'a mut [T];

// core::ptr::NonNull
pub const fn slice_from_raw_parts(data: NonNull<T>, len: usize) -> Self
```

Closes https://github.com/rust-lang/rust/issues/67456.

r? libs-api
2024-10-04 19:19:23 -07:00
Jubilee
882d660036
Rollup merge of #131177 - workingjubilee:stabilize-const-mut-referees, r=tgross35
Stabilize 5 `const_mut_refs`-dependent API

Since `const_mut_refs` and `const_refs_to_cell` have been stabilized, we now may create mutable references inside our library API. Thus we now stabilize the `const fn` version of these public library APIs which required such in their implementation:
- const `NonNull::as_mut` https://github.com/rust-lang/rust/issues/91822#issuecomment-2338930442
- const `slice::{first,last}_mut`: https://github.com/rust-lang/rust/issues/83570#issuecomment-2334847112
- const `str::as_{mut_ptr,bytes_mut}`: https://github.com/rust-lang/rust/issues/130086#issuecomment-2336408562
- const `str::from_utf8_unchecked_mut`: https://github.com/rust-lang/rust/issues/91005#issuecomment-2359820672
- const `UnsafeCell::get_mut`: https://github.com/rust-lang/rust/issues/88836#issuecomment-2359817772
2024-10-04 14:11:37 -07:00
Jubilee
5a8fcab713
Rollup merge of #130518 - scottmcm:stabilize-controlflow-extra, r=dtolnay
Stabilize the `map`/`value` methods on `ControlFlow`

And fix the stability attribute on the `pub use` in `core::ops`.

libs-api in https://github.com/rust-lang/rust/issues/75744#issuecomment-2231214910 seemed reasonably happy with naming for these, so let's try for an FCP.

Summary:
```rust
impl<B, C> ControlFlow<B, C> {
    pub fn break_value(self) -> Option<B>;
    pub fn map_break<T>(self, f: impl FnOnce(B) -> T) -> ControlFlow<T, C>;
    pub fn continue_value(self) -> Option<C>;
    pub fn map_continue<T>(self, f: impl FnOnce(C) -> T) -> ControlFlow<B, T>;
}
```

Resolves #75744

``@rustbot`` label +needs-fcp +t-libs-api -t-libs

---

Aside, in case it keeps someone else from going down the same dead end: I looked at the `{break,continue}_value` methods and tried to make them `const` as part of this, but that's disallowed because of not having `const Drop`, so put it back to not even unstably-const.
2024-10-04 14:11:34 -07:00
okaneco
e08002f6d0 Stabilize BufRead::skip_until 2024-10-04 14:56:15 -04:00
bors
14f303bc14 Auto merge of #130157 - eduardosm:stabilize-const_float_classify, r=RalfJung
Stabilize `const_float_classify`

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

Also reverts https://github.com/rust-lang/rust/pull/114486

Closes https://github.com/rust-lang/rust/issues/72505

Stabilized const API:

```rust
impl f32 {
    pub const fn is_nan(self) -> bool;
    pub const fn is_infinite(self) -> bool;
    pub const fn is_finite(self) -> bool;
    pub const fn is_subnormal(self) -> bool;
    pub const fn is_normal(self) -> bool;
    pub const fn classify(self) -> FpCategory;
    pub const fn is_sign_positive(self) -> bool;
    pub const fn is_sign_negative(self) -> bool;
}

impl f64 {
    pub const fn is_nan(self) -> bool;
    pub const fn is_infinite(self) -> bool;
    pub const fn is_finite(self) -> bool;
    pub const fn is_subnormal(self) -> bool;
    pub const fn is_normal(self) -> bool;
    pub const fn classify(self) -> FpCategory;
    pub const fn is_sign_positive(self) -> bool;
    pub const fn is_sign_negative(self) -> bool;
}
```

cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api`
2024-10-04 18:03:16 +00:00
Matthias Krüger
29580e12f2
Rollup merge of #131197 - EFanZh:avoid-emptyness-check-in-peekmut-pop, r=Amanieu
Avoid emptiness check in `PeekMut::pop`

This PR avoids an unnecessary emptiness check in `PeekMut::pop` by replacing `Option::unwrap` with `Option::unwrap_unchecked`.
2024-10-03 21:52:47 +02:00
EFanZh
d47e388843 Avoid emptiness check in PeekMut::pop 2024-10-03 22:15:52 +08:00
Matthias Krüger
aedf14bb0c
Rollup merge of #131163 - JakenHerman:master, r=Nadrieril
Add `get_line` confusable to `Stdin::read_line()`

This pull request resolves https://github.com/rust-lang/rust/issues/131091

---

I've updated tests for `tests/ui/attributes/rustc_confusables_std_cases` in order to verify this change is working as intended.

Before I submitted this pull request, I had a pull request to my local fork. If you're interested in seeing the conversation on that PR, go to https://github.com/JakenHerman/rust/pull/1.

---

**Testing**:
Run `./x.py test tests/ui/attributes/rustc_confusables_std_cases.rs`
2024-10-03 13:47:59 +02:00
bors
f7c8928f03 Auto merge of #128711 - clarfonthey:default-iters-hash, r=dtolnay
impl `Default` for `HashMap`/`HashSet` iterators that don't already have it

This is a follow-up to #128261 that isn't included in that PR because it depends on:

* [x] rust-lang/hashbrown#542 (`Default`)
* [x] `hashbrown` release containing above

It also wasn't included in #128261 initially and should have its own FCP, since these are also insta-stable.

Changes added:

* `Default for hash_map::{Iter, IterMut, IntoIter, IntoKeys, IntoValues, Keys, Values, ValuesMut}`
* `Default for hash_set::{Iter, IntoIter}`

Changes that were added before FCP, but are being deferred to later:

* `Clone for hash_map::{IntoIter, IntoKeys, IntoValues} where K: Clone, V: Clone`
* `Clone for hash_set::IntoIter where K: Clone`
2024-10-03 08:44:51 +00:00
Jaken Herman
4b48d72eaa Add get_line confusable to Stdin::read_line()
Add tests for addition of `#[rustc_confusables("get_line")]`
2024-10-02 23:19:26 -05:00
ltdk
11f738fcb2 impl Default for Hash{Map,Set} iterators that don't already have it 2024-10-02 23:43:48 -04:00
bors
fd1f8aa05d Auto merge of #127912 - joboet:tls_dtor_thread_current, r=cuviper
std: make `thread::current` available in all `thread_local!` destructors

... and thereby allow the panic runtime to always print the right thread name.

This works by modifying the TLS destructor system to schedule a runtime cleanup function after all other TLS destructors registered by `std` have run. Unfortunately, this doesn't affect foreign TLS destructors, `thread::current` will still panic there.

Additionally, the thread ID returned by `current_id` will now always be available, even inside the global allocator, and will not change during the lifetime of one thread (this was previously the case with key-based TLS).

The mechanisms I added for this (`local_pointer` and `thread_cleanup`) will also allow finally fixing #111272 by moving the signal stack to a similar runtime-cleanup TLS variable.
2024-10-03 03:31:47 +00:00
bors
ad9c494835 Auto merge of #131148 - Urgau:hashbrown-0.15, r=Amanieu
Update hashbrown to 0.15 and adjust some methods

This PR updates `hashbrown` to 0.15 in the standard library and adjust some methods as well as removing some as they no longer exists in Hashbrown it-self.

 - `HashMap::get_many_mut` change API to return array-of-Option
 - `HashMap::{replace_entry, replace_key}` are removed, FCP close [already finished](https://github.com/rust-lang/rust/issues/44286#issuecomment-2293825619)
 - `HashSet::get_or_insert_owned` is removed as it no longer exists in hashbrown

Closes https://github.com/rust-lang/rust/issues/44286
r? `@Amanieu`
2024-10-03 00:44:26 +00:00
Jubilee Young
ac53f1f242 library: Stabilize const_slice_first_last
Const-stabilizes:
- `slice::first_mut`
- `slice::split_first_mut`
- `slice::last_mut`
- `slice::split_last_mut`
2024-10-02 14:10:12 -07:00
Jubilee Young
75db6b29b5 library: Stabilize const_unsafecell_get_mut
Const-stabilizes:
- `UnsafeCell::get_mut`
2024-10-02 14:10:12 -07:00
Jubilee Young
966405d107 library: Stabilize const_ptr_as_ref
Const-stabilizes:
- `NonNull::as_mut`
2024-10-02 14:10:11 -07:00
Jubilee Young
bcc78bdc29 library: Stabilize const_str_as_mut
Const-stabilizes:
- `str::as_bytes_mut`
- `str::as_mut_ptr`
2024-10-02 14:09:19 -07:00
Jubilee Young
a0228686d1 library: Stabilize const_str_from_utf8_unchecked_mut
Const-stabilizes:
- `str::from_utf8_unchecked_mut`
2024-10-02 14:09:19 -07:00
joboet
d868fdce6b
std: make thread::current available in all thread_local! destructors 2024-10-02 18:04:21 +02:00
Matthias Krüger
49f17ff74e
Rollup merge of #131141 - RalfJung:mpmc-test, r=Amanieu
mpmc doctest: make sure main thread waits for child threads

Currently, chances are half the test is not executed because the main thread exits while the other threads are still working.

Cc `@obeis` `@Amanieu`
2024-10-02 17:10:45 +02:00
Urgau
8760a401bd Update hashbrown to 0.15 and adjust some methods
as well as removing some from std as they no longer
exists in Hashbrown it-self.
2024-10-02 09:44:51 +02:00
Ralf Jung
9fa120593e mpmc doctest: make sure main thread waits for child threads 2024-10-02 08:00:17 +02:00
bors
9e3e517446 Auto merge of #130829 - Urgau:option_array_transpose, r=ibraheemdev
Add `[Option<T>; N]::transpose`

This PR as a new unstable libs API, `[Option<T>; N]::transpose`, which permits going from `[Option<T>; N]` to `Option<[T; N]>`.

This new API doesn't have an ACP as it was directly asked by T-libs-api in https://github.com/rust-lang/rust/issues/97601#issuecomment-2372109119:

> [..] but it'd be trivial to provide a helper method `.transpose()` that turns array-of-Option into Option-of-array (**and we think that method should exist**; it already does for array-of-MaybeUninit).

r? libs
2024-10-02 04:31:15 +00:00
bors
bfe5e8cef6 Auto merge of #128204 - GuillaumeGomez:integers-opti, r=workingjubilee
Small optimization for integers Display implementation

This is a first pass to try to speed up a bit integers `Display` implementation. The idea behind this is to reduce the stack usage for the buffer storing the output (shouldn't be visible in bench normally) and some small specialization which benefits a lot to smaller integers like `u8` and `i8`.

Here are the results of the benchmarks:

| bench name | current std | with this PR |
|-|-|-|
| bench_std_fmt::bench_i16_0    | 16.45 ns/iter (+/- 0.25) | 16.50 ns/iter (+/- 0.15) |
| bench_std_fmt::bench_i16_max  | 17.83 ns/iter (+/- 0.66) | 17.58 ns/iter (+/- 0.10) |
| bench_std_fmt::bench_i16_min  | 20.97 ns/iter (+/- 0.49) | 20.50 ns/iter (+/- 0.28) |
| bench_std_fmt::bench_i32_0    | 16.63 ns/iter (+/- 0.06) | 16.62 ns/iter (+/- 0.07) |
| bench_std_fmt::bench_i32_max  | 19.79 ns/iter (+/- 0.43) | 19.55 ns/iter (+/- 0.14) |
| bench_std_fmt::bench_i32_min  | 22.97 ns/iter (+/- 0.50) | 22.08 ns/iter (+/- 0.08) |
| bench_std_fmt::bench_i64_0    | 16.63 ns/iter (+/- 0.39) | 16.69 ns/iter (+/- 0.44) |
| bench_std_fmt::bench_i64_half | 19.60 ns/iter (+/- 0.05) | 19.10 ns/iter (+/- 0.05) |
| bench_std_fmt::bench_i64_max  | 25.22 ns/iter (+/- 0.34) | 24.43 ns/iter (+/- 0.02) |
| bench_std_fmt::bench_i8_0     | 16.27 ns/iter (+/- 0.32) | 15.80 ns/iter (+/- 0.17) |
| bench_std_fmt::bench_i8_max   | 16.71 ns/iter (+/- 0.09) | 16.25 ns/iter (+/- 0.01) |
| bench_std_fmt::bench_i8_min   | 20.07 ns/iter (+/- 0.22) | 19.80 ns/iter (+/- 0.30) |
| bench_std_fmt::bench_u128_0   | 21.37 ns/iter (+/- 0.24) | 21.35 ns/iter (+/- 0.35) |
| bench_std_fmt::bench_u128_max | 48.13 ns/iter (+/- 0.20) | 48.78 ns/iter (+/- 0.29) |
| bench_std_fmt::bench_u16_0    | 16.48 ns/iter (+/- 0.46) | 16.03 ns/iter (+/- 0.39) |
| bench_std_fmt::bench_u16_max  | 17.31 ns/iter (+/- 0.32) | 17.41 ns/iter (+/- 0.32) |
| bench_std_fmt::bench_u16_min  | 16.40 ns/iter (+/- 0.45) | 16.02 ns/iter (+/- 0.39) |
| bench_std_fmt::bench_u32_0    | 16.17 ns/iter (+/- 0.04) | 16.29 ns/iter (+/- 0.16) |
| bench_std_fmt::bench_u32_max  | 19.00 ns/iter (+/- 0.10) | 19.16 ns/iter (+/- 0.28) |
| bench_std_fmt::bench_u32_min  | 16.16 ns/iter (+/- 0.09) | 16.28 ns/iter (+/- 0.11) |
| bench_std_fmt::bench_u64_0    | 16.22 ns/iter (+/- 0.22) | 16.14 ns/iter (+/- 0.18) |
| bench_std_fmt::bench_u64_half | 19.25 ns/iter (+/- 0.07) | 18.95 ns/iter (+/- 0.05) |
| bench_std_fmt::bench_u64_max  | 24.31 ns/iter (+/- 0.08) | 24.18 ns/iter (+/- 0.08) |
| bench_std_fmt::bench_u8_0     | 15.76 ns/iter (+/- 0.08) | 15.66 ns/iter (+/- 0.08) |
| bench_std_fmt::bench_u8_max   | 16.53 ns/iter (+/- 0.03) | 16.29 ns/iter (+/- 0.02) |
| bench_std_fmt::bench_u8_min   | 15.77 ns/iter (+/- 0.06) | 15.67 ns/iter (+/- 0.02) |

The source code is:

<details>
<summary>source code</summary>

```rust
#![feature(test)]
#![allow(non_snake_case)]
#![allow(clippy::cast_lossless)]

extern crate test;

macro_rules! benches {
    ($($name:ident($value:expr))*) => {
        mod bench_std_fmt {
            use std::io::Write;
            use test::{Bencher, black_box};

            $(
                #[bench]
                fn $name(b: &mut Bencher) {
                    let mut buf = Vec::with_capacity(40);

                    b.iter(|| {
                        buf.clear();
                        write!(&mut buf, "{}", black_box($value)).unwrap();
                        black_box(&buf);
                    });
                }
            )*
        }
    }
}

benches! {
    bench_u64_0(0u64)
    bench_u64_half(u32::max_value() as u64)
    bench_u64_max(u64::max_value())

    bench_i64_0(0i64)
    bench_i64_half(i32::max_value() as i64)
    bench_i64_max(i64::max_value())

    bench_u16_0(0u16)
    bench_u16_min(u16::min_value())
    bench_u16_max(u16::max_value())

    bench_i16_0(0i16)
    bench_i16_min(i16::min_value())
    bench_i16_max(i16::max_value())

    bench_u128_0(0u128)
    bench_u128_max(u128::max_value())

    bench_i8_0(0i8)
    bench_i8_min(i8::min_value())
    bench_i8_max(i8::max_value())

    bench_u8_0(0u8)
    bench_u8_min(u8::min_value())
    bench_u8_max(u8::max_value())

    bench_u32_0(0u32)
    bench_u32_min(u32::min_value())
    bench_u32_max(u32::max_value())

    bench_i32_0(0i32)
    bench_i32_min(i32::min_value())
    bench_i32_max(i32::max_value())
}
```

</details>

And then I ran the equivalent code (source code below) in callgrind with [callgrind_differ](https://github.com/Ethiraric/callgrind_differ) to generate a nice output and here's the result:

```
core::fmt::num:👿:<impl core::fmt::Display for i16>::fmt |   1300000 | -    70000 -  5.385%   1230000
core::fmt::num:👿:<impl core::fmt::Display for i32>::fmt |   1910000 | -   100000 -  5.236%   1810000
core::fmt::num:👿:<impl core::fmt::Display for i64>::fmt |   2430000 | -   110000 -  4.527%   2320000
core::fmt::num:👿:<impl core::fmt::Display for i8>::fmt  |   1080000 | -   170000 - 15.741%    910000
core::fmt::num:👿:<impl core::fmt::Display for u16>::fmt |    960000 | +    10000 +  1.042%    970000
core::fmt::num:👿:<impl core::fmt::Display for u32>::fmt |   1300000 | +    30000 +  2.308%   1330000
core::fmt::num:👿:<impl core::fmt::Display for u8>::fmt  |    820000 | -    30000 -  3.659%    790000
```

<details>
<summary>Source code</summary>

```rust
#![feature(test)]

extern crate test;

use std::io::{stdout, Write};
use std::io::StdoutLock;
use test::black_box;

macro_rules! benches {
    ($handle:ident, $buf:ident, $($name:ident($value:expr))*) => {
            $(
                fn $name(handle: &mut StdoutLock, buf: &mut Vec<u8>) {
                    for _ in 0..10000 {
                        buf.clear();
                        write!(buf, "{}", black_box($value)).unwrap();
                        handle.write_all(buf);
                    }
                }
                $name(&mut $handle, &mut $buf);
            )*
    }
}

fn main() {
    let mut handle = stdout().lock();
    let mut buf = Vec::with_capacity(40);

    benches! {
        handle, buf,

        bench_u64_0(0u64)
        bench_u64_half(u32::max_value() as u64)
        bench_u64_max(u64::max_value())

        bench_i64_0(0i64)
        bench_i64_half(i32::max_value() as i64)
        bench_i64_max(i64::max_value())

        bench_u16_0(0u16)
        bench_u16_min(u16::min_value())
        bench_u16_max(u16::max_value())

        bench_i16_0(0i16)
        bench_i16_min(i16::min_value())
        bench_i16_max(i16::max_value())

        bench_u128_0(0u128)
        bench_u128_max(u128::max_value())

        bench_i8_0(0i8)
        bench_i8_min(i8::min_value())
        bench_i8_max(i8::max_value())

        bench_u8_0(0u8)
        bench_u8_min(u8::min_value())
        bench_u8_max(u8::max_value())

        bench_i32_0(0i32)
        bench_i32_min(i32::min_value())
        bench_i32_max(i32::max_value())

        bench_u32_0(0u32)
        bench_u32_min(u32::min_value())
        bench_u32_max(u32::max_value())
    }
}
```

</details>

The next step would be to specialize the `ToString` implementation so it doesn't go through the `Display` trait. I'm not sure if it will improve anything but I think it's worth a try.

r? `@Amanieu`
2024-10-01 22:12:44 +00:00
joboet
c1acccdf17
std: replace LazyBox with OnceBox
This PR replaces the `LazyBox` wrapper used to allocate the pthread primitives with `OnceBox`, which has a more familiar API mirroring that of `OnceLock`. This cleans up the code in preparation for larger changes like #128184 (from which this PR was split) and allows some neat optimizations, like avoid an acquire-load of the allocation pointer in `Mutex::unlock`, where the initialization of the allocation must have already been observed.

Additionally, I've gotten rid of the TEEOS `Condvar` code, it's just a duplicate of the pthread one anyway and I didn't want to repeat myself.
2024-10-01 22:05:35 +02:00
Eduardo Sánchez Muñoz
0dc250c497 Stabilize const_slice_from_raw_parts_mut 2024-10-01 22:02:19 +02:00
bors
06bb8364aa Auto merge of #131111 - matthiaskrgr:rollup-n6do187, r=matthiaskrgr
Rollup of 4 pull requests

Successful merges:

 - #130005 (Replace -Z default-hidden-visibility with -Z default-visibility)
 - #130229 (ptr::add/sub: do not claim equivalence with `offset(c as isize)`)
 - #130773 (Update Unicode escapes in `/library/core/src/char/methods.rs`)
 - #130933 (rustdoc: lists items that contain multiple paragraphs are more clear)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-01 19:29:26 +00:00
Matthias Krüger
a5820b47d1
Rollup merge of #130773 - bjoernager:master, r=thomcc
Update Unicode escapes in `/library/core/src/char/methods.rs`

`char::MAX` is inconsistent on how Unicode escapes should be formatted. This PR resolves that.
2024-10-01 21:09:19 +02:00
Matthias Krüger
97cdc8ef44
Rollup merge of #130229 - RalfJung:ptr-offset-unsigned, r=scottmcm
ptr::add/sub: do not claim equivalence with `offset(c as isize)`

In https://github.com/rust-lang/rust/pull/110837, the `offset` intrinsic got changed to also allow a `usize` offset parameter. The intention is that this will do an unsigned multiplication with the size, and we have UB if that overflows -- and we also have UB if the result is larger than `usize::MAX`, i.e., if a subsequent cast to `isize` would wrap. ~~The LLVM backend sets some attributes accordingly.~~

This updates the docs for `add`/`sub` to match that intent, in preparation for adjusting codegen to exploit this UB. We use this opportunity to clarify what the exact requirements are: we compute the offset using mathematical multiplication (so it's no problem to have an `isize * usize` multiplication, we just multiply integers), and the result must fit in an `isize`.
Cc `@rust-lang/opsem` `@nikic`

https://github.com/rust-lang/rust/pull/130239 updates Miri to detect this UB.

`sub` still has some cases of UB not reflected in the underlying intrinsic semantics (and Miri does not catch): when we subtract `usize::MAX`, then after casting to `isize` that's just `-1` so we end up adding one unit without noticing any UB, but actually the offset we gave does not fit in an `isize`. Miri will currently still not complain for such cases:
```rust
fn main() {
    let x = &[0i32; 2];
    let x = x.as_ptr();
    // This should be UB, we are subtracting way too much.
    unsafe { x.sub(usize::MAX).read() };
}
```
However, the LLVM IR we generate here also is UB-free. This is "just" library UB but not language UB.
Cc `@saethlin;` might be worth adding precondition checks against overflow on `offset`/`add`/`sub`?

Fixes https://github.com/rust-lang/rust/issues/130211
2024-10-01 21:09:19 +02:00
Slanterns
30ff4006e1
update Literal's intro 2024-10-02 01:27:11 +08:00
bors
c817d5dc20 Auto merge of #131098 - GuillaumeGomez:rollup-kk74was, r=GuillaumeGomez
Rollup of 5 pull requests

Successful merges:

 - #130630 (Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly)
 - #131042 (Instantiate binders in `supertrait_vtable_slot`)
 - #131079 (Update wasm-component-ld to 0.5.9)
 - #131085 (make test_lots_of_insertions test take less long in Miri)
 - #131088 (add fixme to remove LLVM_ENABLE_TERMINFO when minimal llvm version is 19)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-01 16:32:19 +00:00
Guillaume Gomez
b9263c6b9f
Rollup merge of #131085 - RalfJung:miri-slow-test, r=tgross35
make test_lots_of_insertions test take less long in Miri

This is by far the slowest `std` test in Miri, taking >2min in https://github.com/rust-lang/miri-test-libstd CI. So let's make this `count` smaller. The runtime should be quadratic in `count` so reducing it to around 2/3 of it's previous value should cut the total time down to less than half -- making it still the slowest test, but by less of a margin. (And this way we still insert >64 elements into the HashMap, in case that power of 2 matters.)
2024-10-01 17:32:09 +02:00
bors
8dd5cd0bc1 Auto merge of #126839 - obeis:mpmc, r=Amanieu
Add multi-producer, multi-consumer channel (mpmc)

Closes #125712

Tracking issue: #126840

r? m-ou-se
2024-10-01 13:35:16 +00:00
Guillaume Gomez
1562bf7909 Remove the need to provide the maximum number of digits to impl_Display macro 2024-10-01 12:01:55 +02:00
Guillaume Gomez
884e0f0a68 Simplify impl_Display macro 2024-10-01 11:51:08 +02:00
Guillaume Gomez
125db409ff Small optimization for integers Display implementation 2024-10-01 11:51:07 +02:00
Ralf Jung
4529b86196 make test_lots_of_insertions test take less long in Miri 2024-10-01 11:03:05 +02:00
Trevor Gross
6b09a93566 Enable f16 tests on non-GNU Windows
There is a MinGW ABI bug that prevents `f16` and `f128` from being
usable on `windows-gnu` targets. This does not affect MSVC; however, we
have `f16` and `f128` tests disabled on all Windows targets.

Update the gating to only affect `windows-gnu`, which means `f16` tests
will be enabled. There is no effect for `f128` since the default
fallback is `false`.
2024-09-30 22:41:19 -04:00
Trevor Gross
a0637597b4
Rollup merge of #130966 - RalfJung:ptr-metadata-const-stable, r=scottmcm
make ptr metadata functions callable from stable const fn

So far this was done with a bunch of `rustc_allow_const_fn_unstable`. But those should be the exception, not the norm. If we are confident we can expose the ptr metadata APIs *indirectly* in stable const fn, we should just mark them as `rustc_const_stable`. And we better be confident we can do that since it's already been done a while ago. ;)

In particular this marks two intrinsics as const-stable: `aggregate_raw_ptr`, `ptr_metadata`. This should be uncontroversial, they are trivial to implement in the interpreter.
Cc `@rust-lang/wg-const-eval` `@rust-lang/lang`
2024-09-30 19:18:51 -04:00
Trevor Gross
40d0ada909
Rollup merge of #130961 - tgross35:f16-x86-apple, r=thomcc
Enable `f16` tests on x86 Apple platforms

These were disabled because Apple uses a special ABI for `f16`. `compiler-builtins` merged a fix for this in [1], which has since propagated to rust-lang/rust. Enable tests since there should be no remaining issues on these platforms.

[1]: https://github.com/rust-lang/compiler-builtins/pull/675

try-job: x86_64-apple-1
try-job: x86_64-apple-2
2024-09-30 19:18:50 -04:00
Trevor Gross
2fe41869c9
Rollup merge of #130914 - compiler-errors:insignificant-dtor, r=Amanieu
Mark some more types as having insignificant dtor

These were caught by https://github.com/rust-lang/rust/pull/129864#issuecomment-2376658407, which is implementing a lint for some changes in drop order for temporaries in tail expressions.

Specifically, the destructors of `CString` and the bitpacked repr for `std::io::Error` are insignificant insofar as they don't have side-effects on things like locking or synchronization; they just free memory.

See some discussion on #89144 for what makes a drop impl "significant"
2024-09-30 19:18:50 -04:00
Trevor Gross
b70654199a
Rollup merge of #129638 - nickrum:wasip2-net, r=alexcrichton
Hook up std::net to wasi-libc on wasm32-wasip2 target

One of the improvements of the `wasm32-wasip2` target over `wasm32-wasip1` is better support for networking. Right now, p2 is just re-using the `std::net` implementation from p1. This PR adds a new net module for p2 that makes use of net from `sys_common` and calls wasi-libc functions directly.

There are currently a few limitations:

- Duplicating a socket is not supported by WASIp2 (directly returns an error)
- Peeking is not yet implemented in wasi-libc (we could let wasi-libc handle this, but I opted to directly return an error instead)
- Vectored reads/writes are not supported by WASIp2 (the necessary functions are available in wasi-libc, but they call WASIp1 functions which do not support sockets, so I opted to directly return an error instead)
- Getting/setting `TCP_NODELAY` is faked in wasi-libc (uses the fake implementation instead of returning an error)
- Getting/setting `SO_LINGER` is not supported by WASIp2 (directly returns an error)
- Setting `SO_REUSEADDR` is faked in wasi-libc (since this is done from `sys_common`, the fake implementation is used instead of returning an error)
- Getting/setting `IPV6_V6ONLY` is not supported by WASIp2 and will always be set for IPv6 sockets (since this is done from `sys_common`, wasi-libc will return an error)
- UDP broadcast/multicast is not supported by WASIp2 (since this is configured from `sys_common`, wasi-libc will return appropriate errors)
- The `MSG_NOSIGNAL` send flag is a no-op because there are no signals in WASIp2 (since explicitly setting this flag would require a change to `sys_common` and the result would be exactly the same, I opted to not set it)

Do those decisions make sense?

While working on this PR, I noticed that there is a `std::os::wasi::net::TcpListenerExt` trait that adds a `sock_accept()` method to `std::net::TcpListener`. Now that WASIp2 supports standard accept, would it make sense to remove this?

cc `@alexcrichton`
2024-09-30 19:18:49 -04:00
Obei Sideg
041e76b7cd
Add multi-producer, multi-consumer channel (mpmc) 2024-09-30 20:43:51 +03:00
Matthias Krüger
a061e566a6
Rollup merge of #130972 - RalfJung:const_cell_into_inner, r=dtolnay
stabilize const_cell_into_inner

This const-stabilizes
- `UnsafeCell::into_inner`
- `Cell::into_inner`
- `RefCell::into_inner`
- `OnceCell::into_inner`

`@rust-lang/wg-const-eval` this uses `rustc_allow_const_fn_unstable(const_precise_live_drops)`, so we'd be comitting to always finding *some* way to accept this code. IMO that's fine -- what these functions do is to move out the only field of a struct, and that struct has no destructor itself. The field's destructor does not get run as it gets returned to the caller.

`@rust-lang/libs-api` this was FCP'd already [years ago](https://github.com/rust-lang/rust/issues/78729#issuecomment-811409860), except that  `OnceCell::into_inner` was added to the same feature gate since then (Cc `@tgross35).` Does that mean we have to re-run the FCP? If yes, I'd honestly prefer to move `OnceCell` into its own feature gate to not risk missing the next release. (That's why it's not great to add new functions to an already FCP'd feature gate.) OTOH if this needs an FCP either way since the previous FCP was so long ago, then we might as well do it all at once.
2024-09-29 20:17:36 +02:00