about summary refs log tree commit diff
path: root/src/libcore/num
AgeCommit message (Collapse)AuthorLines
2018-06-03Rollup merge of #51299 - faern:const-int-ops, r=oli-obkMark Simulacrum-14/+280
const fn integer operations A follow up to #51171 Fixes #51267 Makes a lot of the integer methods (`swap_bytes`, `count_ones` etc) `const fn`s. See #51267 for a discussion about why this is wanted and the solution used.
2018-06-02Rollup merge of #50919 - frewsxcv:frewsxcv-epsilon, r=steveklabnikMark Simulacrum-2/+10
Provide more context for what the {f32,f64}::EPSILON values represent. Introduce the 'machine epsilon' term because if one googles 'epsilon', they might stumble upon https://en.wikipedia.org/wiki/Epsilon_numbers_(mathematics) instead of https://en.wikipedia.org/wiki/Machine_epsilon
2018-06-02Make integer methods non-const in stage0Linus Färnstrand-0/+192
2018-06-02Make most integer operations const fnsLinus Färnstrand-40/+114
2018-06-02Auto merge of #50554 - clarcharr:from_bool, r=TimNNbors-0/+14
Add From<bool> for int types Fixes #46109.
2018-06-01Add From<bool> for int typesClar Charr-0/+14
2018-06-01Add missing whitespace in num exampleGuillaume Gomez-1/+1
2018-05-28Auto merge of #50465 - clarcharr:wrapping, r=KodrAusbors-199/+488
Add missing Wrapping methods, use doc_comment! Re-opened version of #49393 . Finishing touches for #32463. Note that this adds `Shl` and `Shr` implementations for `Wrapping<i128>` and `Wrapping<u128>`, which were previously missed. This is technically insta-stable, but I don't know why this would be a problem.
2018-05-28Provide more context for what the {f32,f64}::EPSILON values represent.Corey Farwell-2/+10
2018-05-22Remove the unstable Float traitSimon Sapin-372/+166
Following up to #49896 and #50629. Fixes #32110. E0689 is weird.
2018-05-17Switch to 1.26 bootstrap compilerMark Simulacrum-8/+2
2018-05-17Rollup merge of #50808 - SimonSapin:nonzero, r=alexcrichtonkennytm-28/+8
Stabilize num::NonZeroU* Tracking issue: https://github.com/rust-lang/rust/issues/49137
2018-05-16Stabilize num::NonZeroU*Simon Sapin-9/+7
Tracking issue: https://github.com/rust-lang/rust/issues/49137
2018-05-16Remove unstable deprecated num::NonZeroI* typesSimon Sapin-17/+1
2018-05-16Make core::nonzero privateSimon Sapin-3/+1
It is now an implementation detail of ptr::NonNull and num::NonZero*
2018-05-16fix a typo in signed-integer::from_str_radix()SHA Miao-1/+1
just a small typo.
2018-05-15Separate feature gate for wrapping_next_power_of_twoClar Charr-4/+6
2018-05-09move See also links to topMichael Lamparski-4/+4
2018-05-08Add missing Wrapping methods, use doc_comment!Clar Charr-199/+486
2018-05-08Add more logarithm constantsClar Charr-0/+16
2018-04-24core: Minor cleanupDaiki Mizukami-1/+1
2018-04-24core: Fix overflow in `int::mod_euc` when `self < 0 && rhs == MIN`Daiki Mizukami-1/+5
2018-04-22Auto merge of #49896 - SimonSapin:inherent, r=alexcrichtonbors-92/+591
Add inherent methods in libcore for [T], [u8], str, f32, and f64 # Background Primitive types are defined by the language, they don’t have a type definition like `pub struct Foo { … }` in any crate. So they don’t “belong” to any crate as far as `impl` coherence is concerned, and on principle no crate would be able to define inherent methods for them, without a trait. Since we want these types to have inherent methods anyway, the standard library (with cooperation from the compiler) bends this rule with code like [`#[lang = "u8"] impl u8 { /*…*/ }`](https://github.com/rust-lang/rust/blob/1.25.0/src/libcore/num/mod.rs#L2244-L2245). The `#[lang]` attribute is permanently-unstable and never intended to be used outside of the standard library. Each lang item can only be defined once. Before this PR there is one impl-coherence-rule-bending lang item per primitive type (plus one for `[u8]`, which overlaps with `[T]`). And so one `impl` block each. These blocks for `str`, `[T]` and `[u8]` are in liballoc rather than libcore because *some* of the methods (like `<[T]>::to_vec(&self) -> Vec<T> where T: Clone`) need a global memory allocator which we don’t want to make a requirement in libcore. Similarly, `impl f32` and `impl f64` are in libstd because some of the methods are based on FFI calls to C’s `libm` and we want, as much as possible, libcore not to require “runtime support”. In libcore, the methods of `str` and `[T]` that don’t allocate are made available through two **unstable traits** `StrExt` and `SliceExt` (so the traits can’t be *named* by programs on the Stable release channel) that have **stable methods** and are re-exported in the libcore prelude (so that programs on Stable can *call* these methods anyway). Non-allocating `[u8]` methods are not available in libcore: https://github.com/rust-lang/rust/issues/45803. Some `f32` and `f64` methods are in an unstable `core::num::Float` trait with stable methods, but that one is **not in the libcore prelude**. (So as far as Stable programs are concerns it doesn’t exist, and I don’t know what the point was to mark these methods `#[stable]`.) https://github.com/rust-lang/rust/issues/32110 is the tracking issue for these unstable traits. # High-level proposal Since the standard library is already bending the rules, why not bend them *a little more*? By defining a few additional lang items, the compiler can allow the standard library to have *two* `impl` blocks (in different crates) for some primitive types. The `StrExt` and `SliceExt` traits still exist for now so that we can bootstrap from a previous-version compiler that doesn’t have these lang items yet, but they can be removed in next release cycle. (`Float` is used internally and needs to be public for libcore unit tests, but was already `#[doc(hidden)]`.) I don’t know if https://github.com/rust-lang/rust/issues/32110 should be closed by this PR, or only when the traits are entirely removed after we make a new bootstrap compiler. # Float methods Among the methods of the `core::num::Float` trait, three are based on LLVM intrinsics: `abs`, `signum`, and `powi`. PR https://github.com/rust-lang/rust/pull/27823 “Remove dependencies on libm functions from libcore” moved a bunch of `core::num::Float` methods back to libstd, but left these three behind. However they aren’t specifically discussed in the PR thread. The `compiler_builtins` crate defines `__powisf2` and `__powidf2` functions that look like implementations of `powi`, but I couldn’t find a connection with the `llvm.powi.f32` and `llvm.powi.f32` intrinsics by grepping through LLVM’s code. In discussion starting at https://github.com/rust-lang/rust/issues/32110#issuecomment-370647922 Alex says that we do not want methods in libcore that require “runtime support”, but it’s not clear whether that applies to these `abs`, `signum`, or `powi`. In doubt, I’ve **removed** them for the trait and moved them to inherent methods in libstd for now. We can move them back later (or in this PR) if we decide that’s appropriate. # Change details For users on the Stable release channel: * I believe this PR does not make any breaking change * Some methods for `[u8]`, `f32`, and `f64` are newly available to `#![no_std]` users (fixes https://github.com/rust-lang/rust/issues/45803) * There should be no visible change for `std` users in terms of what programs compile or what their behavior is. (Only in compiler error messages, possibly.) For Nightly users, additionally: * The unstable `StrExt` and `SliceExt` traits are gone * Their methods are now inherent methods of `str` and `[T]` (so only code that explicitly named the traits should be affected, not "normal" method calls) * The `abs`, `signum` and `powi` methods of the `Float` trait are gone * The `Float` trait’s unstable feature name changed to `float_internals` with no associated tracking issue, to reflect it being a permanently unstable implementation detail rather than a public API on a path to stabilization. * Its remaining methods are now inherent methods of `f32` and `f64`. ----- CC @rust-lang/libs for the API changes, @rust-lang/compiler for the new lang items
2018-04-21Make the unstable StrExt and SliceExt traits private to libcore in not(stage0)Simon Sapin-19/+12
`Float` still needs to be public for libcore unit tests.
2018-04-21Move intrinsics-based float methods out of libcore into libstdSimon Sapin-72/+0
Affected methods are `abs`, `signum`, and `powi`. CC https://github.com/rust-lang/rust/issues/32110#issuecomment-379503183
2018-04-21Add some f32 and f64 inherent methods in libcoreSimon Sapin-1/+579
… previously in the unstable core::num::Float trait. Per https://github.com/rust-lang/rust/issues/32110#issuecomment-379503183, the `abs`, `signum`, and `powi` methods are *not* included for now since they rely on LLVM intrinsics and we haven’t determined yet whether those instrinsics lower to calls to libm functions on any platform.
2018-04-20Revert "Stabilize the TryFrom and TryInto traits"Felix S. Klock II-6/+6
This reverts commit e53a2a72743810e05f58c61c9d8a4c89b712ad2e.
2018-04-14Rollup merge of #49871 - SimonSapin:int-bytes, r=sfacklerkennytm-0/+89
Add to_bytes and from_bytes to primitive integers Discussion issue turned tracking issue: https://github.com/rust-lang/rust/issues/49792
2018-04-14Add to_bytes and from_bytes to primitive integersSimon Sapin-0/+89
2018-04-13Auto merge of #49389 - fanzier:euclidean-division, r=KodrAusbors-0/+440
Implement RFC #2169 (Euclidean modulo). Tracking issue: #49048
2018-04-12Address more nits.Fabian Zaiser-7/+6
2018-03-30Deprecate signed std::num::NonZeroI* with a call for use casesSimon Sapin-7/+23
2018-03-29Fix doctest (typo).Fabian Zaiser-2/+2
2018-03-28Fix #![feature]s.Fabian Zaiser-37/+40
2018-03-28Address nits and tidy errors.Fabian Zaiser-13/+15
2018-03-27Remove TryFrom impls that might become conditionally-infallible with a ↵Simon Sapin-60/+10
portability lint https://github.com/rust-lang/rust/pull/49305#issuecomment-376293243
2018-03-26Stabilize the TryFrom and TryInto traitsSimon Sapin-7/+7
Tracking issue: https://github.com/rust-lang/rust/issues/33417
2018-03-26Don’t use `type Error = !` for target-dependant TryFrom impls.Simon Sapin-1/+1
Instead, expose apparently-fallible conversions in cases where the implementation happens to be infallible for a given target. Having an associated type / return type in a public API change based on the target is a portability hazard.
2018-03-26TryFrom for integers: use From instead for truely-infallible implsSimon Sapin-9/+20
There is precendent in C for having a minimum pointer size, but I don’t feel confident enough about the future to mandate a maximum.
2018-03-26Implement RFC #2169 (Euclidean division).Fabian Zaiser-0/+436
Tracking issue: #49048
2018-03-26fix last two tidyMark Mansi-7/+1
2018-03-26Fix a few moreMark Mansi-2/+2
2018-03-26Fix missed i128 feature gatesMark Mansi-12/+12
2018-03-26Stabilize i128 feature tooMark Mansi-11/+4
2018-03-26Stabilize i128_typeMark Mansi-4/+2
2018-03-23Rollup merge of #48265 - SimonSapin:nonzero, r=KodrAusAlex Crichton-0/+89
Add 12 num::NonZero* types for primitive integers, deprecate core::nonzero RFC: https://github.com/rust-lang/rfcs/pull/2307 Tracking issue: ~~https://github.com/rust-lang/rust/issues/27730~~ https://github.com/rust-lang/rust/issues/49137 Fixes https://github.com/rust-lang/rust/issues/27730
2018-03-22Rollup merge of #49038 - canndrew:replace-infallible-with-never, r=SimonSapinkennytm-9/+8
replace `convert::Infallible` with `!`
2018-03-19Fix trailing whitespacePhlosioneer-1/+1
2018-03-19Make Wrapping::pow use wrapping_pow, add examplePhlosioneer-4/+14
2018-03-19Impl Integer methods for WrappingPhlosioneer-0/+299
Wrapping<T> now implements: count_ones, count_zeros, leading_zeros, trailing_zeros, rotate_left, rotate_right, swap_bytes, from_be, from_le, to_be, to_le, and pow where T is: u8, u16, u32, u64, usize, i8, i16, i32, i64, or isize. Docs were written for all these methods, as well as examples. The examples mirror the ones on u8, u16, etc... for consistency. Closes #32463
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-24 01:57:30 +0000