Tracking Issue for more const int functions #53718

TimDiekmann · 2018-08-26T11:36:32Z

(none exhaustive) list of libcore::num, which should be a const fn:

feature = const_int_rotate
- rotate_left Add more const int ops #53697 -- stabilized
- rotate_right Add more const int ops #53697 -- stabilized
feature = const_checked_int_methods
- checked_add [1] Make more arithmetic functions unstably const #68809
- checked_sub [1] Make more arithmetic functions unstably const #68809
- checked_mul [1] Make more arithmetic functions unstably const #68809
- checked_div [1] Make more arithmetic functions unstably const #68809
- checked_rem [1] Make more arithmetic functions unstably const #68809
- checked_neg [1] Make more arithmetic functions unstably const #68809
- checked_shl [1] Make more arithmetic functions unstably const #68809
- checked_shr [1] Make more arithmetic functions unstably const #68809
- checked_abs [1] Make more arithmetic functions unstably const #68809
feature = const_saturating_int_methods
- saturating_add Make saturating_add and saturating_sub const functions #58246
- saturating_sub Make saturating_add and saturating_sub const functions #58246
- saturating_mul [1] Make more arithmetic functions unstably const #68809
feature = const_int_wrapping
- wrapping_add Add more const int ops #53697 -- stabilized
- wrapping_sub Add more const int ops #53697 -- stabilized
- wrapping_mul Add more const int ops #53697 -- stabilized
- wrapping_div [1] Make more arithmetic functions unstably const #68809
- wrapping_rem [1] Make more arithmetic functions unstably const #68809
- wrapping_neg Make overflowing and wrapping negation const #58044 -- stabilized
- wrapping_shl Add more const int ops #53697 -- stabilized
- wrapping_shr Add more const int ops #53697 -- stabilized
- wrapping_abs Make abs, wrapping_abs, overflowing_abs const functions #63786 -- stabilized in 1.39
feature = const_int_overflowing
- overflowing_add Add more const int ops #53697
- overflowing_sub Add more const int ops #53697
- overflowing_mul Add more const int ops #53697
- overflowing_div [1] Make more arithmetic functions unstably const #68809
- overflowing_rem [1] Make more arithmetic functions unstably const #68809
- overflowing_neg Make overflowing and wrapping negation const #58044 -- stabilized
- overflowing_shl Add more const int ops #53697
- overflowing_shr Add more const int ops #53697
- overflowing_abs Make abs, wrapping_abs, overflowing_abs const functions #63786 -- stabilized in 1.39
feature = const_euclidean_int_methods
- checked_div_euc [1] Make more arithmetic functions unstably const #68809
- checked_mod_euc [1] Make more arithmetic functions unstably const #68809
- wrapping_div_euc [1] Make more arithmetic functions unstably const #68809
- wrapping_mod_euc [1] Make more arithmetic functions unstably const #68809
- overflowing_div_euc [1] Make more arithmetic functions unstably const #68809
- overflowing_mod_euc [1] Make more arithmetic functions unstably const #68809
feature = const_int_pow
- pow[1, 2] Make integer exponentiation methods unstably const #68978
- is_power_of_two make is_power_of_two a const function #65092
- next_power_of_two [1] Make integer exponentiation methods unstably const #68978
- checked_pow [1] Make integer exponentiation methods unstably const #68978
- checked_next_power_of_two [1] Make integer exponentiation methods unstably const #68978
- saturating_pow [1, 2] Make integer exponentiation methods unstably const #68978
- wrapping_pow [1, 2] Make integer exponentiation methods unstably const #68978
- wrapping_next_power_of_two [1] Make integer exponentiation methods unstably const #68978
- overflowing_pow [1, 2] Make integer exponentiation methods unstably const #68978
feature = const_int_sign
- abs Make abs, wrapping_abs, overflowing_abs const functions #63786 -- stabilized in 1.39
- signum Make i*::signum a const fn. #61635
- is_positive Add more const int ops #53697 -- stabilized
- is_negative Add more const int ops #53697 -- stabilized
feature = const_int_conversion
- to_be_bytes Add more const int ops #53697
- to_le_bytes Add more const int ops #53697
- to_ne_bytes Add more const int ops #53697
- from_be_bytes Add more const int ops #53697
- from_le_bytes Add more const int ops #53697
- from_ne_bytes Add more const int ops #53697
- reverse_bits Add more const int ops #53697
feature = const_nonzero_int_methods
- NonZero*::new [1] Make num::NonZeroX::new an unstable const fn #68976

Requires conditionals. Tracking Issue: Tracking issue for RFC 2342, "Allow if and match in constants" #49146 (implemented on nightly)
Requires loops. Tracking Issue: Tracking issue for RFC 2344, "Allow loop in constant evaluation" #52000 (implemented on nightly)

This issue has been assigned to @9999years via this comment.

The text was updated successfully, but these errors were encountered:

TheDarkula · 2018-08-30T17:43:46Z

transmute() just got merged. You can start on your last block now :)

TimDiekmann · 2018-08-31T04:52:49Z

@TheDarkula Thank you, I'll start implementing them as soon as #53699 is merged.

TimDiekmann · 2018-08-31T23:16:25Z

Added rest of const_int_conversion to #53697

TimDiekmann · 2018-09-01T12:32:09Z

I'm currently rebasing #53697 and testing. Then the first bunch should be ready to merge.

@oli-obk

Add more const int ops r? @oli-obk Tracking Issue: #53718 list of `const fn`s in this PR: - `feature = const_int_rotate` - `rotate_left` - `rotate_right` - `feature = const_int_wrapping` - `wrapping_add` - `wrapping_sub` - `wrapping_mul` - `wrapping_shl` - `wrapping_shr` - `feature = const_int_overflowing` - `overflowing_add` - `overflowing_sub` - `overflowing_mul` - `overflowing_shl` - `overflowing_shr` - `feature = const_int_sign` - `is_positive` - `is_negative` - `feature = const_int_conversion` - `reverse_bits` - `to_le_bytes` - `to_ne_bytes` - `from_be_bytes` - `from_le_bytes` - `from_ne_bytes` - `reverse_bits`

mjbshaw · 2018-12-31T00:22:24Z

Adding a comment here so I don't have to hunt for the following related issue: #51267 is the tracking issue for feature = const_int_ops, which tracks:

count_zeros -- stabilized
count_ones -- stabilized
leading_zeros -- stabilized
trailing_zeros -- stabilized

Lokathor · 2019-01-13T01:46:18Z

wrapping_neg isn't on the list here it seems (though overflowing_neg is)

ecstatic-morse · 2019-06-08T00:08:34Z

It's possible to make a great number of these const without conditional statements being legal in const fn by using indexing (e.g. [x, -x][(x < 0) as usize]). However, it's a bad idea because the technique results in much less efficient generated code. You can check this by viewing ASM in the previous link. I'm posting this to avoid duplication of effort in case someone else has the same idea.

mark-i-m · 2019-06-08T02:15:29Z

In fact, we are already doing that to make Vec::new() a const fn 😛

rust/src/liballoc/raw_vec.rs

Lines 51 to 63 in d132f54

    
           pub const fn new_in(a: A) -> Self { 
        
               // !0 is usize::MAX. This branch should be stripped at compile time. 
        
               // FIXME(mark-i-m): use this line when `if`s are allowed in `const` 
        
               //let cap = if mem::size_of::<T>() == 0 { !0 } else { 0 }; 
        
               // Unique::empty() doubles as "unallocated" and "zero-sized allocation" 
        
               RawVec { 
        
                   ptr: Unique::empty(), 
        
                   // FIXME(mark-i-m): use `cap` when ifs are allowed in const 
        
                   cap: [0, !0][(mem::size_of::<T>() == 0) as usize], 
        
                   a, 
        
               } 
        
           }

ecstatic-morse · 2019-06-08T03:15:27Z

@mark-i-m That's probably where I first saw this technique!

My point was that making a similar modification would likely slow down these arithmetic operations considerably. The use in Vec::new can be eliminated via const-propagation post-monomorphization, but that optimization doesn't apply here.

Make `i*::signum` a `const fn`. Ticks a box in #53718. This uses a well-known branchless implementation of `signum`: `(n > 0) as i32 - (n < 0) as i32`. Here's a [playground](https://play.rust-lang.org/?version=nightly&mode=release&edition=2018&gist=747cf191c4974bf66c9d75e509ae6e6e) comparing the two techniques. On x86 in release mode, the branchless implementation is able to replace a `mov` and `cmov` with a `sar` and `add`, so this should be a bit faster as well. ~~This is marked as a draft since I think I'll need to add `#[rustc_const_unstable]` somewhere. Perhaps the reviewer can point me in the right direction.~~

ecstatic-morse · 2019-06-08T17:48:56Z

@TimDiekmann. Now that #61635 has been merged, signum is an unstable const fn. Could you edit the initial post to reflect this?

mjbshaw · 2019-07-06T22:06:23Z

Some of these could be made const today without conditionals. For unsigned:

overflowing_div
wrapping_div
wrapping_div_euclid
wrapping_rem
wrapping_rem_euclid
overflowing_div
overflowing_div_euclid
overflowing_rem
overflowing_rem_euclid
div_euclid
rem_euclid
is_power_of_two

For u8:

is_ascii

mjbshaw · 2019-07-06T22:35:52Z

Also, wrapping_neg and overflowing_neg should be updated in the OP. Both were made const in #58044

jonas-schievink · 2019-11-04T17:21:38Z

is_power_of_two and next_power_of_two shouldn't require conditionals. See https://graphics.stanford.edu/~seander/bithacks.html#DetermineIfPowerOf2 (replacing && with &) and https://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2, respectively.

ecstatic-morse · 2019-11-04T17:35:53Z

@jonas-schievink is_power_of_two was recently constified. I've updated the original post.

Currently, next_power_of_two uses a non-zero count trailing zeros intrinsic, so it might be hard to constify without regressing performance. It would be a good first issue for someone to try this out and see though.

ecstatic-morse · 2019-11-04T19:21:50Z

Actually, quite a few of these are now implemented. I've edited the post to reflect this. If anyone sees something out-of-date, let me know.

mjbshaw · 2019-11-05T16:17:04Z

@ecstatic-morse The intrinsic can be const and implemented in miri. That's what's done for trailing_zeros, for example.

ecstatic-morse · 2019-11-05T16:47:17Z

You need to handle zero somehow without branching, and you need to do so without regressing performance for non-const code.

(Also, I meant leading zeros above, my bad).

SimonSapin · 2019-11-25T19:59:05Z

Should NonZero*::new fall in this category?

With rust-lang#49146 merged, NonZero*::new can be const; see rust-lang#53718.

With rust-lang#49146 merged, {u8,i8,u16,...}::overflowing_div and ::overflowing_rem can be const; see rust-lang#53718.

With rust-lang#49146 merged, these can be const; see rust-lang#53718.

@9999years

… r=oli-obk Make more arithmetic functions unstably const This is a smaller version of rust-lang#66884 (thanks @9999years) that constifies many of the arithmetic functions on integer primitives from rust-lang#53718 that were blocked on rust-lang#49146. This makes the following things unstably const. - `feature = const_int_unchecked_arith` - `intrinsics::unchecked_add` - `intrinsics::unchecked_sub` - `intrinsics::unchecked_mul` - `intrinsics::unchecked_div` - `intrinsics::unchecked_rem` - `feature = const_checked_int_methods` - `checked_add` - `checked_sub` - `checked_mul` - `checked_div` (Uses `intrinsics::unchecked_div` internally) - `checked_rem` (Uses `intrinsics::unchecked_rem` internally) - `checked_neg` - `checked_shl` - `checked_shr` - `checked_abs` - `feature = const_saturating_int_methods` - `saturating_mul` - `saturating_neg` (Uses `intrinsics::unchecked_sub` internally) - `saturating_abs` (Uses `intrinsics::unchecked_sub` internally) - `feature = const_wrapping_int_methods` - `wrapping_div` - `wrapping_rem` - `feature = const_overflowing_int_methods` - `overflowing_div` - `overflowing_rem` - `feature = const_euclidean_int_methods` - `checked_div_euclid` - `checked_rem_euclid` - `wrapping_div_euclid` - `wrapping_rem_euclid` - `overflowing_div_euclid` - `overflowing_rem_euclid` Exponentiation and operations on the `NonZero` types are left to a later PR. r? @oli-obk cc @rust-lang/wg-const-eval @rust-lang/libs

…olnay Make `num::NonZeroX::new` an unstable `const fn` cc rust-lang#53718 These require `#[feature(const_if_match)]`, meaning they must remain unstable for the time being.

ecstatic-morse · 2020-02-10T19:01:06Z

@rustbot release-assignment

shamatar · 2020-02-14T14:54:47Z

Are these changes alone sufficient to allow to use arithmetic ops like “+” in a constant context or does is require landing of const traits (for e.g. std::ops::Add)?

…-obk Make integer exponentiation methods unstably const cc rust-lang#53718 This makes the following inherent methods on integer primitives into unstable `const fn`: - `pow` - `checked_pow` - `wrapping_pow` - `overflowing_pow` - `saturating_pow` - `next_power_of_two` - `checked_next_power_of_two` - `wrapping_next_power_of_two` Only two changes were made to the implementation of these methods. First, I had to switch from the `?` operator, which is not yet implemented in a const context, to a `try_opt` macro. Second, `next_power_of_two` was using `ops::Add::add` (see the first commit) to "get overflow checks", so I switched to `#[rustc_inherit_overflow_checks]`. I'm not quite sure why the attribute wasn't used in the first place.

tspiteri · 2020-02-21T16:31:35Z

I think that the {to,from}_{be,le,ne}_bytes methods should be made const in stable. While it is true that currently the implementation depends on e.g. transmute, that is a hidden implementation detail, and they could already be implemented as const stably with e.g. b[3] << 24 | b[2] << 16 | b[1] << 8 | b[0]. Of course, I'm not suggesting that the implementation itself should be changed, just that it should not stop them from being marked const in stable.

jhpratt · 2020-05-03T05:51:01Z

Would a PR making .rem_euclid a const fn on stable be accepted? It could be trivially implemented as ((x % y) + y) % y. This reasoning has been used for other methods in the past.

tspiteri · 2020-05-03T10:56:06Z

@jhpratt

It doesn't give the same results for negative y. 3.rem_euclid(-2) == 1, but ((3 % (-2)) + (-2)) % (-2) == -1. This could be solved by using y.abs().

But it would overflow for example when x == i32::MAX - 1 && y == i32::MAX.

myrrlyn · 2020-05-07T02:37:21Z

Can we stabilize the const_int_conversion gate, or is there a standing issue preventing stabilization? As has been mentioned upthread, these functions have equivalent const-able expressions, but as they are still unstable, these must be copied into each crate that needs them. This copying is bug-prone, so stabilization would reduce duplication and the possibility of error production.

tspiteri · 2020-05-07T05:19:18Z

@myrrlyn It's already stabilized in beta.

Razican · 2020-09-10T09:04:54Z

Hello, as far as I can tell, both [1] and [2] are now stable, right? so there is no extra blocking issue to implement/stabilize those, right? Is there something that can be done to get them stabilized?

tspiteri · 2020-09-10T13:10:32Z

@Razican Most of [1] were marked stable in #73858, so they will be stabilized in 1.47. The PR did not include division and remainder because they can panic, so maybe they need another footnote.

To stabilize the rest that can be stabilized (the pow functions I think), someone needs to write a PR, which will then need to be approved, pass through FCP, and get merged.

jhpratt · 2021-01-13T02:43:55Z

#80962 is up to stabilize all remaining methods mentioned at the top of this issue. The diagnostic on nightly is functionally the same as already-stable equivalents (5 % 0 vs 5.rem_euclid(0), for example).

TimDiekmann mentioned this issue Aug 26, 2018

Add more const int ops #53697

Merged

Centril mentioned this issue Dec 24, 2018

Stablilize const_int_{rotate,wrapping,sign} #57105

Closed

Centril closed this as completed Jan 13, 2019

Centril reopened this Jan 13, 2019

Lokathor mentioned this issue Jan 13, 2019

Meta tracking issue for const fn #57563

Open

25 tasks

ecstatic-morse mentioned this issue Jun 7, 2019

Make i*::signum a const fn. #61635

Merged

ecstatic-morse mentioned this issue Oct 4, 2019

constify some checked arithmetics #65107

Closed

9999years added a commit to 9999years/rust that referenced this issue Dec 19, 2019

Make NonZero*::new const

20db398

With rust-lang#49146 merged, NonZero*::new can be const; see rust-lang#53718.

9999years added a commit to 9999years/rust that referenced this issue Dec 19, 2019

Make overflowing_div and overflowing_rem const

09994af

With rust-lang#49146 merged, {u8,i8,u16,...}::overflowing_div and ::overflowing_rem can be const; see rust-lang#53718.

9999years added a commit to 9999years/rust that referenced this issue Dec 19, 2019

Make wrapping int fns const

17ab2c4

With rust-lang#49146 merged, these can be const; see rust-lang#53718.

9999years added a commit to 9999years/rust that referenced this issue Dec 19, 2019

Make saturating int fns const

e749327

With rust-lang#49146 merged, these can be const; see rust-lang#53718.

9999years added a commit to 9999years/rust that referenced this issue Dec 19, 2019

Make Euclidean int fns const

5909f54

With rust-lang#49146 merged, these can be const; see rust-lang#53718.

CDirkx mentioned this issue Jan 26, 2020

Add const inherent comparison methods to integers. #68557

Closed

ecstatic-morse mentioned this issue Feb 3, 2020

Make more arithmetic functions unstably const #68809

Merged

This was referenced Feb 9, 2020

Make num::NonZeroX::new an unstable const fn #68976

Merged

Make integer exponentiation methods unstably const #68978

Merged

ecstatic-morse mentioned this issue Apr 20, 2020

Tracking issue for RFC 2342, "Allow if and match in constants" #49146

Closed

4 tasks

jamwaffles mentioned this issue May 19, 2020

Use const fn for constructors embedded-graphics/embedded-graphics#205

Open

KodrAus added B-unstable Blocker: Implemented in the nightly compiler and unstable. Libs-Tracked Libs issues that are tracked on the team's project board. labels Jul 29, 2020

jhpratt mentioned this issue Jan 13, 2021

Stabilize remaining integer methods as const fn #80962

Merged

bors closed this as completed in 4940dd4 Feb 8, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking Issue for more const int functions #53718

Tracking Issue for more const int functions #53718

TimDiekmann commented Aug 26, 2018 •

edited by ecstatic-morse

Loading

TheDarkula commented Aug 30, 2018

TimDiekmann commented Aug 31, 2018

TimDiekmann commented Aug 31, 2018

TimDiekmann commented Sep 1, 2018

mjbshaw commented Dec 31, 2018 •

edited by Centril

Loading

Lokathor commented Jan 13, 2019

ecstatic-morse commented Jun 8, 2019

mark-i-m commented Jun 8, 2019

ecstatic-morse commented Jun 8, 2019

ecstatic-morse commented Jun 8, 2019

mjbshaw commented Jul 6, 2019

mjbshaw commented Jul 6, 2019

jonas-schievink commented Nov 4, 2019

ecstatic-morse commented Nov 4, 2019 •

edited

Loading

ecstatic-morse commented Nov 4, 2019

mjbshaw commented Nov 5, 2019

ecstatic-morse commented Nov 5, 2019 •

edited

Loading

SimonSapin commented Nov 25, 2019

ecstatic-morse commented Feb 10, 2020

shamatar commented Feb 14, 2020

tspiteri commented Feb 21, 2020

jhpratt commented May 3, 2020

tspiteri commented May 3, 2020 •

edited

Loading

myrrlyn commented May 7, 2020

tspiteri commented May 7, 2020

Razican commented Sep 10, 2020

tspiteri commented Sep 10, 2020

jhpratt commented Jan 13, 2021

Tracking Issue for more const int functions #53718

Tracking Issue for more const int functions #53718

Comments

TimDiekmann commented Aug 26, 2018 • edited by ecstatic-morse Loading

TheDarkula commented Aug 30, 2018

TimDiekmann commented Aug 31, 2018

TimDiekmann commented Aug 31, 2018

TimDiekmann commented Sep 1, 2018

mjbshaw commented Dec 31, 2018 • edited by Centril Loading

Lokathor commented Jan 13, 2019

ecstatic-morse commented Jun 8, 2019

mark-i-m commented Jun 8, 2019

ecstatic-morse commented Jun 8, 2019

ecstatic-morse commented Jun 8, 2019

mjbshaw commented Jul 6, 2019

mjbshaw commented Jul 6, 2019

jonas-schievink commented Nov 4, 2019

ecstatic-morse commented Nov 4, 2019 • edited Loading

ecstatic-morse commented Nov 4, 2019

mjbshaw commented Nov 5, 2019

ecstatic-morse commented Nov 5, 2019 • edited Loading

SimonSapin commented Nov 25, 2019

ecstatic-morse commented Feb 10, 2020

shamatar commented Feb 14, 2020

tspiteri commented Feb 21, 2020

jhpratt commented May 3, 2020

tspiteri commented May 3, 2020 • edited Loading

myrrlyn commented May 7, 2020

tspiteri commented May 7, 2020

Razican commented Sep 10, 2020

tspiteri commented Sep 10, 2020

jhpratt commented Jan 13, 2021

TimDiekmann commented Aug 26, 2018 •

edited by ecstatic-morse

Loading

mjbshaw commented Dec 31, 2018 •

edited by Centril

Loading

ecstatic-morse commented Nov 4, 2019 •

edited

Loading

ecstatic-morse commented Nov 5, 2019 •

edited

Loading

tspiteri commented May 3, 2020 •

edited

Loading