Commit Graph

364 Commits

Author SHA1 Message Date
Ralf Jung
a8d11ea20e stabilize const_nonnull_new 2024-12-10 11:29:01 +01:00
bors
75716b4510 Auto merge of #118159 - EliasHolzmann:formatting_options, r=m-ou-se
Implementation of `fmt::FormattingOptions`

Tracking issue: #118117

Public API:
```rust
#[derive(Copy, Clone, Debug, PartialEq, Eq)]
pub struct FormattingOptions { … }
#[derive(Copy, Clone, Debug, PartialEq, Eq)]
pub enum Sign {
    Plus,
    Minus
}
#[derive(Copy, Clone, Debug, PartialEq, Eq)]
pub enum DebugAsHex {
    Lower,
    Upper
}

impl FormattingOptions {
    pub fn new() -> Self;
    pub fn sign(&mut self, sign: Option<Sign>) -> &mut Self;
    pub fn sign_aware_zero_pad(&mut self, sign_aware_zero_pad: bool) -> &mut Self;
    pub fn alternate(&mut self, alternate: bool) -> &mut Self;
    pub fn fill(&mut self, fill: char) -> &mut Self;
    pub fn align(&mut self, alignment: Option<Alignment>) -> &mut Self;
    pub fn width(&mut self, width: Option<usize>) -> &mut Self;
    pub fn precision(&mut self, precision: Option<usize>) -> &mut Self;
    pub fn debug_as_hex(&mut self, debug_as_hex: Option<DebugAsHex>) -> &mut Self;

    pub fn get_sign(&self) -> Option<Sign>;
    pub fn get_sign_aware_zero_pad(&self) -> bool;
    pub fn get_alternate(&self) -> bool;
    pub fn get_fill(&self) -> char;
    pub fn get_align(&self) -> Option<Alignment>;
    pub fn get_width(&self) -> Option<usize>;
    pub fn get_precision(&self) -> Option<usize>;
    pub fn get_debug_as_hex(&self) -> Option<DebugAsHex>;

    pub fn create_formatter<'a>(self, write: &'a mut (dyn Write + 'a)) -> Formatter<'a>;
    }

impl<'a> Formatter<'a> {
    pub fn new(write: &'a mut (dyn Write + 'a), options: FormattingOptions) -> Self;
    pub fn with_options<'b>(&'b mut self, options: FormattingOptions) -> Formatter<'b>;
    pub fn sign(&self) -> Option<Sign>;

    pub fn options(&self) -> FormattingOptions;
}
```

Relevant changes from the public API in the tracking issue (I'm leaving out some stuff I consider obvious mistakes, like missing `#[derive(..)]`s and `pub` specifiers):

- `enum DebugAsHex`/`FormattingOptions::debug_as_hex`/`FormattingOptions::get_debug_as_hex`: To support `{:x?}` as well as `{:X?}`. I had completely missed these options in the ACP. I'm open for any and all bikeshedding, not married to the name.
- `fill`/`get_fill` now takes/returns `char` instead of `Option<char>`. This simply mirrors what `Formatter::fill` returns (with default being `' '`).
- Changed `zero_pad`/`get_zero_pad` to `sign_aware_zero_pad`/`get_sign_aware_zero_pad`. This also mirrors `Formatter::sign_aware_zero_pad`. While I'm not a fan of this quite verbose name, I do believe that having the interface of `Formatter` and `FormattingOptions` be compatible is more important.
- For the same reason, renamed `alignment`/`get_alignment` to `aling`/`get_align`.
- Deviating from my initial idea, `Formatter::with_options` returns a `Formatter` which has the lifetime of the `self` reference as its generic lifetime parameter (in the original API spec, the generic lifetime of the returned `Formatter` was the generic lifetime used by `self` instead). Otherwise, one could construct two `Formatter`s that both mutably borrow the same underlying buffer, which would be unsound. This solution still has performance benefits over simply using `Formatter::new`, so I believe it is worthwhile to keep this method.
2024-12-06 22:28:42 +00:00
Eric Holk
72ce1ab42f
Stabilize noop_waker
Co-authored-by: zachs18 <8355914+zachs18@users.noreply.github.com>
2024-12-05 14:14:17 -08:00
Elias Holzmann
f17d13285c Added struct fmt::FormattingOptions
This allows to build custom `std::Formatter`s at runtime.

Also added some related enums and two related methods on `std::Formatter`.
2024-12-05 21:48:01 +01:00
Ralf Jung
2b88e4c716 stabilize const_{size,align}_of_val 2024-12-02 20:18:25 +01:00
bors
3bff51ea91 Auto merge of #133728 - jhpratt:rollup-k1i60pg, r=jhpratt
Rollup of 4 pull requests

Successful merges:

 - #133589 (Remove `hir::ArrayLen`)
 - #133672 (Remove a bunch of unnecessary const stability noise)
 - #133678 (Stabilize `ptr::fn_addr_eq`)
 - #133727 (Update mailmap)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-12-02 12:17:12 +00:00
Jacob Pratt
8f7a10670f
Rollup merge of #133672 - RalfJung:const-stability-cleanup, r=jhpratt
Remove a bunch of unnecessary const stability noise
2024-12-01 22:10:23 -05:00
Jacob Pratt
5880752b9a
Rollup merge of #131784 - Urgau:stabilize-midpoint, r=dtolnay
Stabilize unsigned and float variants of `num_midpoint` feature

This PR proposes that we stabilize the unsigned variants of the [`num_midpoint`](https://github.com/rust-lang/rust/issues/110840#issue-1684506201) feature as well as the floats variants, since they are not subject to any unresolved questions, which is equivalent to doing `(a + b) / 2` (and `(a + b) >> 1`) in a sufficiently large number.

The stabilized API surface would be:

```rust
/// Calculates the middle point of `self` and `rhs`.
///
/// `midpoint(a, b)` is `(a + b) / 2` as if it were performed in a sufficiently-large unsigned integral type.
/// This implies that the result is always rounded towards negative infinity and that no overflow will ever occur.

impl u{8,16,32,64,128,size} {
    pub const fn midpoint(self, rhs: Self) -> Self;
}

impl NonZeroU{8,16,32,64,size} {
    pub const fn midpoint(self, rhs: Self) -> Self;
}

impl f{32,64} {
    pub const fn midpoint(self, rhs: Self) -> Self;
}
```

The signed variants `u{8,16,32,64,128,size}` would remain gated, until a decision is made about the rounding mode, in other words that the [unresolved questions](https://github.com/rust-lang/rust/issues/110840#issue-1684506201) are resolved.

cc `@rust-lang/libs-api`
cc `@scottmcm`
r? libs-api
2024-12-01 21:38:24 -05:00
Urgau
b88478f707 Stabilize unsigned num_midpoint feature 2024-12-01 11:28:53 +01:00
Ralf Jung
2a05e5be4f add test for bytewise ptr::swap of a pointer 2024-11-30 10:42:17 +01:00
Ralf Jung
0dc94404ee remove a whole bunch of unnecessary const feature gates 2024-11-30 10:23:39 +01:00
Boxy
22998f0785 update cfgs 2024-11-27 15:14:54 +00:00
George Bateman
5777c73438 Stabilize const_pin_2 2024-11-20 07:54:12 -05:00
Ralf Jung
324d059962 stabilize const_option_ext 2024-11-12 21:42:15 +01:00
Ralf Jung
5069434c81 most const intrinsics don't need an explicit rustc_const_unstable any more 2024-11-04 23:27:46 +01:00
Jubilee
3313e760d0
Rollup merge of #132423 - RalfJung:const-eval-align-offset, r=dtolnay
remove const-support for align_offset and is_aligned

As part of the recent discussion to stabilize `ptr.is_null()` in const context, the general vibe was that it's okay for a const function to panic when the same operation would work at runtime (that's just a case of "dynamically detecting that something is not supported as a const operation"), but it is *not* okay for a const function to just return a different result.

Following that, `is_aligned` and `is_aligned_to` have their const status revoked in this PR, since they do return actively wrong results at const time. In the future we can consider having a new intrinsic or so that can check whether a pointer is "guaranteed to be aligned", but the current implementation based on `align_offset` does not have the behavior we want.

In fact `align_offset` itself behaves quite strangely in const, and that support needs a bunch of special hacks. That doesn't seem worth it. Instead, the users that can fall back to a different implementation should just use const_eval_select directly, and everything else should not be made const-callable. So this PR does exactly that, and entirely removes const support for align_offset.

Closes some tracking issues by removing the associated features:
Closes https://github.com/rust-lang/rust/issues/90962
Closes https://github.com/rust-lang/rust/issues/104203

Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api`
2024-11-03 20:08:13 -08:00
Ralf Jung
19e287060d remove const-support for align_offset
Operations like is_aligned would return actively wrong results at compile-time,
i.e. calling it on the same pointer at compiletime and runtime could yield
different results. That's no good.

Instead of having hacks to make align_offset kind-of work in const-eval, just
use const_eval_select in the few places where it makes sense, which also ensures
those places are all aware they need to make sure the fallback behavior is
consistent.
2024-11-03 17:00:44 +01:00
Matthias Krüger
e9379382f9
Rollup merge of #132503 - RalfJung:const-hash-map, r=Amanieu
better test for const HashMap; remove const_hash leftovers

The existing `const_with_hasher` test is kind of silly since the HashMap it constructs can never contain any elements. So this adjusts the test to construct a usable HashMap, which is a bit non-trivial since the default hash builder cannot be built in `const`. `BuildHasherDefault::new()` helps but is unstable (https://github.com/rust-lang/rust/issues/123197), so we also have a test that does not involve that type.

The second commit removes the last remnants of https://github.com/rust-lang/rust/issues/104061, since they aren't actually useful -- without const traits, you can't do any hashing in `const`.

Cc ``@rust-lang/libs-api`` ``@rust-lang/wg-const-eval``
Closes #104061
Related to https://github.com/rust-lang/rust/issues/102575
2024-11-03 12:08:52 +01:00
Ralf Jung
52666238cf remove const_hash feature leftovers 2024-11-02 11:27:14 +01:00
Ralf Jung
66351a6184 get rid of a whole bunch of unnecessary rustc_const_unstable attributes 2024-11-02 09:59:55 +01:00
Matthias Krüger
81d885b933
Rollup merge of #131391 - ChaiTRex:isqrt, r=scottmcm,tgross35
Stabilize `isqrt` feature

Stabilizes the `isqrt` feature. FCP is incomplete.

Closes #116226
2024-10-28 12:14:57 +01:00
Ralf Jung
16b9bb744d get rid of the internal unlikely macro 2024-10-25 20:31:40 +02:00
Ralf Jung
a0215d8e46 Re-do recursive const stability checks
Fundamentally, we have *three* disjoint categories of functions:
1. const-stable functions
2. private/unstable functions that are meant to be callable from const-stable functions
3. functions that can make use of unstable const features

This PR implements the following system:
- `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions.
- `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category.
- `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls.

Also, several holes in recursive const stability checking are being closed.
There's still one potential hole that is hard to avoid, which is when MIR
building automatically inserts calls to a particular function in stable
functions -- which happens in the panic machinery. Those need to *not* be
`rustc_const_unstable` (or manually get a `rustc_const_stable_indirect`) to be
sure they follow recursive const stability. But that's a fairly rare and special
case so IMO it's fine.

The net effect of this is that a `#[unstable]` or unmarked function can be
constified simply by marking it as `const fn`, and it will then be
const-callable from stable `const fn` and subject to recursive const stability
requirements. If it is publicly reachable (which implies it cannot be unmarked),
it will be const-unstable under the same feature gate. Only if the function ever
becomes `#[stable]` does it need a `#[rustc_const_unstable]` or
`#[rustc_const_stable]` marker to decide if this should also imply
const-stability.

Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to
use unstable const lang features (including intrinsics), or (b) `#[stable]`
functions that are not yet intended to be const-stable. Adding
`#[rustc_const_stable]` is only needed for functions that are actually meant to
be directly callable from stable const code. `#[rustc_const_stable_indirect]` is
used to mark intrinsics as const-callable and for `#[rustc_const_unstable]`
functions that are actually called from other, exposed-on-stable `const fn`. No
other attributes are required.
2024-10-25 20:31:40 +02:00
Matthias Krüger
38eaf608eb
Rollup merge of #131707 - clarfonthey:constify-core-tests, r=thomcc
Run most `core::num` tests in const context too

This adds some infrastructure for something I was going to use in #131566, but it felt worthwhile enough on its own to merge/discuss separately.

Essentially, right now we tend to rely on UI tests to ensure that things work in const context, rather than just using library tests. This uses a few simple macro tricks to make it *relatively* painless to execute tests in both runtime and compile-time context. And this only applies to the numeric tests, and not anything else.

Recommended to review without whitespace in the diff.

cc `@RalfJung`
2024-10-23 06:51:23 +02:00
Ralf Jung
56ee492a6e move strict provenance lints to new feature gate, remove old feature gates 2024-10-21 15:22:17 +01:00
George Bateman
24810b0036
Partially stabilize const_pin 2024-10-16 21:24:38 +01:00
Josh Stone
acb09bf741 update bootstrap configs 2024-10-15 20:30:23 -07:00
ltdk
362879d8c1 Run most core::num tests in const context too 2024-10-14 16:37:57 -04:00
Matthias Krüger
5d63a3db9c
Rollup merge of #131616 - RalfJung:const_ip, r=tgross35
merge const_ipv4 / const_ipv6 feature gate into 'ip' feature gate

https://github.com/rust-lang/rust/issues/76205 has been closed a while ago, but there are still some functions that reference it. Those functions are all unstable *and* const-unstable. There's no good reason to use a separate feature gate for their const-stability, so this PR moves their const-stability under the same gate as their regular stability, and therefore removes the remaining references to https://github.com/rust-lang/rust/issues/76205.
2024-10-14 06:04:29 +02:00
Matthias Krüger
e01eae72da
Rollup merge of #130629 - Dirbaio:net-from-octets, r=tgross35
core/net: add Ipv[46]Addr::from_octets, Ipv6Addr::from_segments.

Adds:

- `Ipv4Address::from_octets([u8;4])`
- `Ipv6Address::from_octets([u8;16])`
- `Ipv6Address::from_segments([u16;8])`

equivalent to the existing `From` impls.

Advantages:

- Consistent with `to_bits, from_bits`.
- More discoverable than the `From` impls.
- Helps with type inference: it's common to want to convert byte slices to IP addrs. If you try this

```rust
fn foo(x: &[u8]) -> Ipv4Addr {
   Ipv4Addr::from(foo.try_into().unwrap())
}
```

it [doesn't work](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0e2873312de275a58fa6e33d1b213bec). You have to write `Ipv4Addr::from(<[u8;4]>::try_from(x).unwrap())` instead, which is not great. With `from_octets` it is able to infer the right types.

Found this while porting [smoltcp](https://github.com/smoltcp-rs/smoltcp/) from its own IP address types to the `core::net` types.

~~Tracking issues #27709 #76205~~
Tracking issue: https://github.com/rust-lang/rust/issues/131360
2024-10-14 06:04:27 +02:00
Dario Nieuwenhuis
725d1f7905 core/net: add Ipv[46]Addr::from_octets, Ipv6Addr::from_segments 2024-10-13 20:26:23 +02:00
Ralf Jung
1ebfd97051 merge const_ipv4 / const_ipv6 feature gate into 'ip' feature gate 2024-10-13 09:55:34 +02:00
Trevor Gross
19f6c17df4 Stabilize const_option
This makes the following API stable in const contexts:

    impl<T> Option<T> {
        pub const fn as_mut(&mut self) -> Option<&mut T>;
        pub const fn expect(self, msg: &str) -> T;
        pub const fn unwrap(self) -> T;
        pub const unsafe fn unwrap_unchecked(self) -> T;
        pub const fn take(&mut self) -> Option<T>;
        pub const fn replace(&mut self, value: T) -> Option<T>;
    }

    impl<T> Option<&T> {
        pub const fn copied(self) -> Option<T>
        where T: Copy;
    }

    impl<T> Option<&mut T> {
        pub const fn copied(self) -> Option<T>
        where T: Copy;
    }

    impl<T, E> Option<Result<T, E>> {
        pub const fn transpose(self) -> Result<Option<T>, E>
    }

    impl<T> Option<Option<T>> {
        pub const fn flatten(self) -> Option<T>;
    }

The following functions make use of the unstable
`const_precise_live_drops` feature:

- `expect`
- `unwrap`
- `unwrap_unchecked`
- `transpose`
- `flatten`

Fixes: <https://github.com/rust-lang/rust/issues/67441>
2024-10-12 17:07:13 -04:00
Trevor Gross
8a86f1dd8c
Rollup merge of #130954 - workingjubilee:stabilize-const-mut-fn, r=RalfJung
Stabilize const `ptr::write*` and `mem::replace`

Since `const_mut_refs` and `const_refs_to_cell` have been stabilized, we may now also stabilize the ability to write to places during const evaluation inside our library API. So, we now propose the `const fn` version of `ptr::write` and its variants. This allows us to also stabilize `mem::replace` and `ptr::replace`.
- const `mem::replace`: https://github.com/rust-lang/rust/issues/83164#issuecomment-2338660862
- const `ptr::write{,_bytes,_unaligned}`: https://github.com/rust-lang/rust/issues/86302#issuecomment-2330275266

Their implementation requires an additional internal stabilization of `const_intrinsic_forget`, which is required for `*::write*` and thus `*::replace`. Thus we const-stabilize the internal intrinsics `forget`, `write_bytes`, and `write_via_move`.
2024-10-12 11:08:42 -05:00
Jubilee Young
ddc367ded7 library: Stabilize const_ptr_write
Const-stabilizes:
- `write`
- `write_bytes`
- `write_unaligned`

In the following paths:
- `core::ptr`
- `core::ptr::NonNull`
- pointer `<*mut T>`

Const-stabilizes the internal `core::intrinsics`:
- `write_bytes`
- `write_via_move`
2024-10-12 00:02:36 -07:00
Trevor Gross
3e16b77465
Rollup merge of #131289 - RalfJung:duration_consts_float, r=tgross35
stabilize duration_consts_float

Waiting for FCP in https://github.com/rust-lang/rust/issues/72440 to pass.

`as_millis_f32` and `as_millis_f64` are not stable at all yet, so I moved their const-stability together with their regular stability (tracked at https://github.com/rust-lang/rust/issues/122451).

Fixes https://github.com/rust-lang/rust/issues/72440
2024-10-11 23:57:45 -04:00
Trevor Gross
622fc5e0f3
Rollup merge of #131287 - RalfJung:const_result, r=tgross35
stabilize const_result

Waiting for FCP to complete in https://github.com/rust-lang/rust/issues/82814

Fixes #82814
2024-10-11 16:53:48 -05:00
Trevor Gross
8797cfed68
Rollup merge of #131109 - tgross35:stabilize-debug_more_non_exhaustive, r=joboet
Stabilize `debug_more_non_exhaustive`

Fixes: https://github.com/rust-lang/rust/issues/127942
2024-10-11 16:53:47 -05:00
Ralf Jung
92f65684a8 stabilize const_result 2024-10-11 18:34:28 +02:00
Ralf Jung
181e667626 stabilize duration_consts_float 2024-10-11 18:23:30 +02:00
ultrabear
461b49d96d
stabilize {slice,array}::from_mut 2024-10-09 00:38:01 -07:00
Chai T. Rex
f954bab4f1 Stabilize isqrt feature 2024-10-08 10:58:49 -04: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 Young
966405d107 library: Stabilize const_ptr_as_ref
Const-stabilizes:
- `NonNull::as_mut`
2024-10-02 14:10:11 -07:00
Trevor Gross
2bc2304e30 Stabilize debug_more_non_exhaustive
Fixes: https://github.com/rust-lang/rust/issues/127942
2024-10-01 14:42:16 -04:00
Ralf Jung
ac488a2c3f stabilize const_cell_into_inner 2024-09-28 11:29:02 +02:00
Ralf Jung
2787179f53 stabilize const_intrinsic_copy 2024-09-23 22:12:54 +02:00
ultrabear
63f14b3a1e
remove feature attributes as const_maybe_uninit_as_mut_ptr is stabilized 2024-09-18 20:22:10 -07:00
Jubilee
12b59e52bc
Rollup merge of #130476 - workingjubilee:more-lazy-methods-take-2, r=Amanieu
Implement ACP 429: add `Lazy{Cell,Lock}::get[_mut]` and `force_mut`

Tracking issue for `lazy_get`: https://github.com/rust-lang/rust/issues/129333
2024-09-18 14:32:26 -07:00
Jubilee Young
d9cdb71497 library: Destabilize Lazy{Cell,Lock}::{force,deref}_mut 2024-09-18 11:39:21 -07:00