summary refs log tree commit diff
path: root/src/libcore/num
AgeCommit message (Collapse)AuthorLines
2020-03-04Auto merge of #68952 - faern:stabilize-assoc-int-consts, r=dtolnaybors-210/+255
Stabilize assoc_int_consts associated int/float constants The next step in RFC https://github.com/rust-lang/rfcs/pull/2700 (tracking issue #68490). Stabilizing the associated constants that were added in #68325. * Stabilize all constants under the `assoc_int_consts` feature flag. * Update documentation on old constants to say they are soft-deprecated and the new ones should be preferred. * Update documentation examples to use new constants. * Remove `uint_macro` and use `int_macro` for all integer types since the macros were identical anyway. r? @LukasKalbertodt
2020-02-26Rollup merge of #69209 - Mark-Simulacrum:strip-unsafe, r=dtolnayDylan DPC-17/+15
Miscellaneous cleanup to formatting Each commit stands alone. This pull request will also resolve #58320.
2020-02-22Rollup merge of #68984 - ecstatic-morse:const-u8-is-ascii, r=sfacklerDylan DPC-1/+2
Make `u8::is_ascii` a stable `const fn` `char::is_ascii` was already stabilized as `const fn` in #55278, so there is no reason for `u8::is_ascii` to go through an unstable period. cc @rust-lang/libs
2020-02-20Rollup merge of #68978 - ecstatic-morse:const-int-pow, r=oli-obkDylan DPC-23/+46
Make integer exponentiation methods unstably const cc #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.
2020-02-17Drop unused argument to float functionsMark Rousskov-2/+0
2020-02-16Stabilize {f32, f64}::{LOG2_10, LOG10_2}LeSeulArtichaut-4/+4
2020-02-15Formatter::sign is &'static strMark Rousskov-15/+15
The contents were always UTF-8 anyway, and &str has an equivalent representation to &[u8], so this should not affect performance while removing unsafety at edges. It may be worth exploring a further adjustment that stores a single byte (instead of 16) as the contents are always "", "-", or "+".
2020-02-12Add usage recommendation to old float constantsLinus Färnstrand-0/+28
2020-02-12Update float documentation to use associated constsLinus Färnstrand-22/+2
2020-02-12Add notice about using new consts in new code on int modulesLinus Färnstrand-0/+36
2020-02-12Add notice about using new consts in new code on float modulesLinus Färnstrand-0/+6
2020-02-12Remove uint_macros that was identical to int_macrosLinus Färnstrand-41/+13
2020-02-12Replace min/max_value() with MIN/MAX in integer docsLinus Färnstrand-52/+52
2020-02-12Use new preferred consts in int docsLinus Färnstrand-35/+13
2020-02-12Add "soft deprecation" notice to old MIN/MAX docsLinus Färnstrand-12/+41
2020-02-12Add "soft deprecation" notice to old min/max_value() docsLinus Färnstrand-40/+60
2020-02-12Stabilize assoc_int_constsLinus Färnstrand-36/+32
2020-02-10Rollup merge of #68986 - ecstatic-morse:const-ascii-ctype, r=CentrilDylan DPC-10/+20
Make ASCII ctype functions unstably const Makes the following inherent methods on `u8` and `char` unstable `const fn`: * `is_ascii_alphabetic` * `is_ascii_uppercase` * `is_ascii_lowercase` * `is_ascii_alphanumeric` * `is_ascii_digit` * `is_ascii_hexdigit` * `is_ascii_punctuation` * `is_ascii_graphic` * `is_ascii_whitespace` * `is_ascii_control` cc #68983
2020-02-08Make `u8::is_ascii` a stable `const fn`Dylan MacKenzie-1/+2
`char::is_ascii` is already a stable `const fn`, so there is no reason for `u8::is_ascii` to be unstable.
2020-02-08Make the ASCII ctype inherent methods constDylan MacKenzie-10/+20
2020-02-08Make integer power methods constDylan MacKenzie-14/+28
2020-02-08Use bespoke macro instead of `?` inside const fnsDylan MacKenzie-6/+16
2020-02-08[!] Use `rustc_inherit_overflow_checks` in `next_power_of_two`Dylan MacKenzie-3/+2
I believe the previous code was calling `ops::Add::add` instead of the `+` operator to get this behavior.
2020-02-08Make `num::NonZeroX::new` an unstable `const fn`Dylan MacKenzie-1/+2
2020-02-04Use consistent feature namingDylan MacKenzie-45/+45
2020-02-04Make saturating arithmetic using intrinsics `const`Dylan MacKenzie-2/+4
2020-02-04Make checked division `const`Dylan MacKenzie-4/+8
2020-02-04Make wrapping arithmetic `const`Dylan MacKenzie-4/+8
Co-Authored-By: 9999years <rbt@sent.as>
2020-02-04Make `saturating_mul` a `const fn`Dylan MacKenzie-6/+12
Co-Authored-By: 9999years <rbt@sent.as>
2020-02-04Make overflowing arithmetic `const`Dylan MacKenzie-4/+8
Co-Authored-By: 9999years <rbt@sent.as>
2020-02-04Make checked arithmetic besides division `const`Dylan MacKenzie-13/+26
Co-Authored-By: 9999years <rbt@sent.as>
2020-02-04Make euclidean division `const`Dylan MacKenzie-16/+32
Co-Authored-By: 9999years <rbt@sent.as>
2020-01-30Auto merge of #68325 - faern:move-numeric-consts-to-associated-consts-step1, ↵bors-56/+191
r=LukasKalbertodt Move numeric consts to associated consts step1 A subset of #67913. Implements the first step of RFC https://github.com/rust-lang/rfcs/pull/2700 This PR adds the new constants as unstable constants and defines the old ones in terms of the new ones. Then fix a tiny bit of code that started having naming collisions because of the new assoc consts. Removed a test that did not seem relevant any longer. Since doing just `u8::MIN` should now indeed be valid.
2020-01-29Document `From` implementation for NonZero numsLeSeulArtichaut-2/+6
2020-01-23Unlock assoc_int_consts in documentation examples using itLinus Färnstrand-0/+4
2020-01-23Fix some float operations to work together with the assoc constsLinus Färnstrand-5/+5
2020-01-23Add relevant associated constants to the float typesLinus Färnstrand-28/+135
2020-01-23Add MIN/MAX associated constants to the integer typesLinus Färnstrand-23/+47
2020-01-15Mark leading_trailing_ones with tracking issue 57969Thom Chiovoloni-4/+4
2020-01-12Add {leading,trailing}_ones to primitive int typesThom Chiovoloni-0/+83
2020-01-09Rollup merge of #67966 - popzxc:core-std-matches, r=CentrilMazdak Farrokhzad-40/+10
Use matches macro in libcore and libstd This PR replaces matches like ```rust match var { value => true, _ => false, } ``` with use of `matches!` macro. r? @Centril
2020-01-09Rollup merge of #67884 - anp:allow-unused-const-attr, r=oli-obkMazdak Farrokhzad-0/+3
Fix incremental builds of core by allowing unused attribute. I *think* that the same problem as in https://github.com/rust-lang/rust/issues/65023 was introduced by https://github.com/rust-lang/rust/pull/67657. This works around the current incrcomp issue with these attributes by allowing it here. This resolves the near-term issue for me, at least.
2020-01-08Use matches macro in libcore and libstdIgor Aleksanov-40/+10
2020-01-06Use Self instead of $typeLzu Tao-2/+2
2020-01-04Fix incremental builds of core by allowing unused attribute.Adam Perry-0/+3
The same problem as in https://github.com/rust-lang/rust/issues/65023 was introduced by https://github.com/rust-lang/rust/pull/67657. This works around the current incrcomp issue with these attributes by allowing it here.
2020-01-05Re-add comment about behaviour of inline.jumbatm-0/+3
2020-01-04Also remove const-hack for absjumbatm-18/+6
2019-12-31Rollup merge of #67430 - tspiteri:minus-inf, r=Dylan-DPCDylan DPC-2/+2
doc: minus (U+2212) instead of dash (U+002D) for negative infinity The documentation for [`f32::NEG_INFINITY`](https://doc.rust-lang.org/std/f32/constant.NEG_INFINITY.html) contains “-∞” with a dash instead of a minus sign, “−∞” with a proper minus sign looks better with the used Source Serif Pro font. Similarly for [`f64::NEG_INFINITY`](https://doc.rust-lang.org/std/f64/constant.NEG_INFINITY.html).
2019-12-30Rollup merge of #67657 - jumbatm:cleanup-const-hack, r=oli-obkYuki Okushi-12/+17
Clean up const-hack PRs now that const if / match exist. Closes #67627. Cleans up these merged PRs tagged with `const-hack`: - #63810 - #63786 - #61635 - #58044 reverting their contents to have the match or if expressions they originally contained. r? @oli-obk There's one more PR in those tagged with `const-hack` that originally wasn't merged (#65107). Reading the thread, it looks like it was originally closed because the `const-hack` for the checked arithmetic non-negligibly hurt performance, and because there was no way to manipulate the returned Option at compile time anyway (with neither const if nor const match). Would you like me to add these changes to the changes from this PR here too, now that we have the necessary features?
2019-12-27Clean up const-hack from #58044jumbatm-1/+6
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 14:08:44 +0000