Tracking Issue for more const int functions

@9999years

(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.

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

@TheDarkula

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

Added rest of const_int_conversion to #53697

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

Auto merge of #53697 - Cyres:const-fn-int-ops, r=oli-obk

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

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

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.

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, 
        
                   } 
        
               }

@mark-i-m

@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.

Rollup merge of rust-lang#68978 - ecstatic-morse:const-int-pow, r=oli…

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.

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.

@jhpratt

@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.

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.

@myrrlyn

@myrrlyn It's already stabilized in beta.

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?

@Razican

@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.

#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).

Auto merge of rust-lang#80962 - jhpratt:const_int_fn-stabilization, r…

Navigation Menu

Repository navigation

Tracking Issue for more const int functions #53718

38 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	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,
	}
	}

Tracking Issue for more const int functions #53718

Description

Activity

TheDarkula commented on Aug 30, 2018

TimDiekmann commented on Aug 31, 2018

TimDiekmann commented on Aug 31, 2018

TimDiekmann commented on Sep 1, 2018

mjbshaw commented on Dec 31, 2018

Lokathor commented on Jan 13, 2019

ecstatic-morse commented on Jun 8, 2019

mark-i-m commented on Jun 8, 2019

ecstatic-morse commented on Jun 8, 2019

38 remaining items

tspiteri commented on Feb 21, 2020

jhpratt commented on May 3, 2020

tspiteri commented on May 3, 2020

myrrlyn commented on May 7, 2020

tspiteri commented on May 7, 2020

Razican commented on Sep 10, 2020

tspiteri commented on Sep 10, 2020

jhpratt commented on Jan 13, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions