summary refs log tree commit diff
path: root/src/libcore/num
AgeCommit message (Collapse)AuthorLines
2020-07-02Rollup merge of #73938 - nbdd0121:checked_opt, r=nagisaManish Goregaokar-27/+43
Optimise fast path of checked_ops with `unlikely` This PR marks paths returning `None` in checked_ops as unlikely to improvde codegen. Fixes #73731
2020-07-01Optimise fast path of checked_ops with `unlikely`Gary Guo-27/+43
2020-06-30Deny unsafe ops in unsafe fns, part 6LeSeulArtichaut-3/+0
And final part!!!
2020-06-30Deny unsafe ops in unsafe fns, part 3LeSeulArtichaut-9/+29
2020-06-29Auto merge of #73032 - yoshuawuyts:stabilize-leading_trailing_ones, r=Amanieubors-12/+12
stabilize leading_trailing_ones This PR stabilizes the `leading_trailing_ones` feature. It's been available on nightly since the start of the year, and hasn't had any issues since. It seems unlikely we'll want to change this, so following up on @djc's suggestion in https://github.com/rust-lang/rust/issues/57969#issuecomment-638405264 I'd like to put forward this PR to stabilize the feature and make it part of `1.46.0`. Thanks! cc/ @djc @rust-lang/libs
2020-06-28Remove `const_if_match` feature gate from librariesDylan MacKenzie-3/+3
2020-06-12Rollup merge of #72906 - lzutao:migrate-numeric-assoc-consts, r=dtolnayDylan DPC-37/+36
Migrate to numeric associated consts The deprecation PR is #72885 cc #68490 cc rust-lang/rfcs#2700
2020-06-11Update src/libcore/num/mod.rsAmanieu d'Antras-2/+2
Co-authored-by: lzutao <taolzu@gmail.com>
2020-06-10Fix doctest templateMihail Malo-1/+2
`saturating_add` example was not parameterized, but passed because the `u8` would saturate successfully
2020-06-10Migrate to numeric associated constsLzu Tao-37/+36
2020-06-05stabilize leading_trailing_onesYoshua Wuyts-12/+12
2020-06-01Add associated consts MIN/MAX for Wrapping<Int>Lzu Tao-12/+4
2020-05-26Add tracing issue for total_cmpPyry Kontio-2/+2
2020-05-26Fix the same typos again orzPyry Kontio-4/+4
2020-05-26Add bit twiddlingPyry Kontio-15/+19
2020-05-26remove unneeded and unidiomatic must_usePyry Kontio-2/+0
2020-05-26Fix typo in src/libcore/num/f32.rsPyry Kontio-1/+1
Co-authored-by: bluss <bluss@users.noreply.github.com>
2020-05-26Fix typo in src/libcore/num/f32.rsPyry Kontio-1/+1
Co-authored-by: bluss <bluss@users.noreply.github.com>
2020-05-25Add total_cmp to f32 and f64, plus testsPyry Kontio-0/+146
2020-05-19Rollup merge of #71886 - t-rapp:tr-saturating-funcs, r=dtolnayDylan DPC-6/+4
Stabilize saturating_abs and saturating_neg Stabilizes the following signed integer functions with saturation mechanics: * saturating_abs() * saturating_neg() Closes #59983
2020-05-16Rollup merge of #72224 - lzutao:links, r=Dylan-DPCDylan DPC-8/+8
doc: add links to rotate_(left|right)
2020-05-15Auto merge of #69659 - CAD97:step-rework-take-3, r=Amanieubors-0/+102
Rework the std::iter::Step trait Previous attempts: #43127 #62886 #68807 Tracking issue: #42168 This PR reworks the `Step` trait to be phrased in terms of the *successor* and *predecessor* operations. With this, `Step` hopefully has a consistent identity that can have a path towards stabilization. The proposed trait: ```rust /// Objects that have a notion of *successor* and *predecessor* operations. /// /// The *successor* operation moves towards values that compare greater. /// The *predecessor* operation moves towards values that compare lesser. /// /// # Safety /// /// This trait is `unsafe` because its implementation must be correct for /// the safety of `unsafe trait TrustedLen` implementations, and the results /// of using this trait can otherwise be trusted by `unsafe` code to be correct /// and fulful the listed obligations. pub unsafe trait Step: Clone + PartialOrd + Sized { /// Returns the number of *successor* steps required to get from `start` to `end`. /// /// Returns `None` if the number of steps would overflow `usize` /// (or is infinite, or if `end` would never be reached). /// /// # Invariants /// /// For any `a`, `b`, and `n`: /// /// * `steps_between(&a, &b) == Some(n)` if and only if `Step::forward(&a, n) == Some(b)` /// * `steps_between(&a, &b) == Some(n)` if and only if `Step::backward(&a, n) == Some(a)` /// * `steps_between(&a, &b) == Some(n)` only if `a <= b` /// * Corollary: `steps_between(&a, &b) == Some(0)` if and only if `a == b` /// * Note that `a <= b` does _not_ imply `steps_between(&a, &b) != None`; /// this is the case wheen it would require more than `usize::MAX` steps to get to `b` /// * `steps_between(&a, &b) == None` if `a > b` fn steps_between(start: &Self, end: &Self) -> Option<usize>; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self`, returns `None`. /// /// # Invariants /// /// For any `a`, `n`, and `m`: /// /// * `Step::forward_checked(a, n).and_then(|x| Step::forward_checked(x, m)) == Step::forward_checked(a, m).and_then(|x| Step::forward_checked(x, n))` /// /// For any `a`, `n`, and `m` where `n + m` does not overflow: /// /// * `Step::forward_checked(a, n).and_then(|x| Step::forward_checked(x, m)) == Step::forward_checked(a, n + m)` /// /// For any `a` and `n`: /// /// * `Step::forward_checked(a, n) == (0..n).try_fold(a, |x, _| Step::forward_checked(&x, 1))` /// * Corollary: `Step::forward_checked(&a, 0) == Some(a)` fn forward_checked(start: Self, count: usize) -> Option<Self>; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self`, /// this function is allowed to panic, wrap, or saturate. /// The suggested behavior is to panic when debug assertions are enabled, /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a`, `n`, and `m`, where no overflow occurs: /// /// * `Step::forward(Step::forward(a, n), m) == Step::forward(a, n + m)` /// /// For any `a` and `n`, where no overflow occurs: /// /// * `Step::forward_checked(a, n) == Some(Step::forward(a, n))` /// * `Step::forward(a, n) == (0..n).fold(a, |x, _| Step::forward(x, 1))` /// * Corollary: `Step::forward(a, 0) == a` /// * `Step::forward(a, n) >= a` /// * `Step::backward(Step::forward(a, n), n) == a` fn forward(start: Self, count: usize) -> Self { Step::forward_checked(start, count).expect("overflow in `Step::forward`") } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow, use `forward` or `forward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b > a`, it is safe to call `Step::forward_unchecked(a, 1)` /// * if there exists `b`, `n` such that `steps_between(&a, &b) == Some(n)`, /// it is safe to call `Step::forward_unchecked(a, m)` for any `m <= n`. /// /// For any `a` and `n`, where no overflow occurs: /// /// * `Step::forward_unchecked(a, n)` is equivalent to `Step::forward(a, n)` #[unstable(feature = "unchecked_math", reason = "niche optimization path", issue = "none")] unsafe fn forward_unchecked(start: Self, count: usize) -> Self { Step::forward(start, count) } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self`, returns `None`. /// /// # Invariants /// /// For any `a`, `n`, and `m`: /// /// * `Step::backward_checked(a, n).and_then(|x| Step::backward_checked(x, m)) == n.checked_add(m).and_then(|x| Step::backward_checked(a, x))` /// * `Step::backward_checked(a, n).and_then(|x| Step::backward_checked(x, m)) == try { Step::backward_checked(a, n.checked_add(m)?) }` /// /// For any `a` and `n`: /// /// * `Step::backward_checked(a, n) == (0..n).try_fold(a, |x, _| Step::backward_checked(&x, 1))` /// * Corollary: `Step::backward_checked(&a, 0) == Some(a)` fn backward_checked(start: Self, count: usize) -> Option<Self>; /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self`, /// this function is allowed to panic, wrap, or saturate. /// The suggested behavior is to panic when debug assertions are enabled, /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a`, `n`, and `m`, where no overflow occurs: /// /// * `Step::backward(Step::backward(a, n), m) == Step::backward(a, n + m)` /// /// For any `a` and `n`, where no overflow occurs: /// /// * `Step::backward_checked(a, n) == Some(Step::backward(a, n))` /// * `Step::backward(a, n) == (0..n).fold(a, |x, _| Step::backward(x, 1))` /// * Corollary: `Step::backward(a, 0) == a` /// * `Step::backward(a, n) <= a` /// * `Step::forward(Step::backward(a, n), n) == a` fn backward(start: Self, count: usize) -> Self { Step::backward_checked(start, count).expect("overflow in `Step::backward`") } /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow, use `backward` or `backward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b < a`, it is safe to call `Step::backward_unchecked(a, 1)` /// * if there exists `b`, `n` such that `steps_between(&b, &a) == Some(n)`, /// it is safe to call `Step::backward_unchecked(a, m)` for any `m <= n`. /// /// For any `a` and `n`, where no overflow occurs: /// /// * `Step::backward_unchecked(a, n)` is equivalent to `Step::backward(a, n)` #[unstable(feature = "unchecked_math", reason = "niche optimization path", issue = "none")] unsafe fn backward_unchecked(start: Self, count: usize) -> Self { Step::backward(start, count) } } ``` Note that all of these are associated functions and not callable via method syntax; the calling syntax is always `Step::forward(start, n)`. This version of the trait additionally changes the stepping functions to talk their arguments by value. As opposed to previous attempts which provided a "step by one" method directly, this version of the trait only exposes "step by n". There are a few reasons for this: - `Range*`, the primary consumer of `Step`, assumes that the "step by n" operation is cheap. If a single step function is provided, it will be a lot more enticing to implement "step by n" as n repeated calls to "step by one". While this is not strictly incorrect, this behavior would be surprising for anyone used to using `Range<{primitive integer}>`. - With a trivial default impl, this can be easily added backwards-compatibly later. - The debug-wrapping "step by n" needs to exist for `RangeFrom` to be consistent between "step by n" and "step by one" operation. (Note: the behavior is not changed by this PR, but making the behavior consistent is made tenable by this PR.) Three "kinds" of step are provided: `_checked`, which returns an `Option` indicating attempted overflow; (unsuffixed), which provides "safe overflow" behavior (is allowed to panic, wrap, or saturate, depending on what is most convenient for a given type); and `_unchecked`, which is a version which assumes overflow does not happen. Review is appreciated to check that: - The invariants as described on the `Step` functions are enough to specify the "common sense" consistency for successor/predecessor. - Implementation of `Step` functions is correct in the face of overflow and the edges of representable integers. - Added tests of `Step` functions are asserting the correct behavior (and not just the implemented behavior).
2020-05-15doc: add links to rotate_(left|right)Lzu Tao-8/+8
2020-05-10doc: minus (U+2212) instead of dash (U+002D) for negative infinityTrevor Spiteri-2/+2
2020-05-05Rollup merge of #71845 - steveklabnik:add-const-examples, r=dtolnayDylan DPC-2/+318
Add const examples I only added them to `std::f32` to get feedback on this approach before adding the other constants. When looking at https://github.com/rust-lang/rust/pull/68952, I found the docs a little confusing. Unless you're intimately aware of what's going on here, I don't think it's super clear what is deprecated and what you're supposed to do instead. I think short examples really clarify what's meant here, so that's what I did.
2020-05-04Stabilize saturating_abs and saturating_negTobias Rapp-6/+4
Stabilizes the following signed integer functions with saturation mechanics: * saturating_abs() * saturating_neg() Closes #59983
2020-05-04Use f64 in f64 examplesSteve Klabnik-2/+2
I believe that this is a copy/paste error; this example was using f32, but it's the docs for f64.
2020-05-04Add examples to int macrosSteve Klabnik-2/+24
2020-05-04f64 examplesSteve Klabnik-0/+147
2020-05-04correct -> intendedSteve Klabnik-14/+14
2020-05-04add some whitespaceSteve Klabnik-0/+7
2020-05-04Add examples for std::f32 constants.Steve Klabnik-0/+140
And also point people to use the associated constants of f32 instead.
2020-04-26Fix since attribute for nonzero_bitor impl'sJonas Platte-5/+5
2020-04-25Rollup merge of #69813 - thomcc:nonzero-bitor, r=AmanieuDylan DPC-0/+52
Implement BitOr and BitOrAssign for the NonZero integer types This provides overloaded operators for `NonZero$Int | NonZero$Int`, `NonZero$Int | $Int`, and `$Int | NonZero$Int`. It also provides `BitOrAssign` where `self` is `NonZero$Int`, for symmetry. It's a pretty small conceptual addition, but is good becasue but avoids a case where the operation is obviously sound, but you'd otherwise need unsafe to do it. In crates trying to minimize `unsafe` usage, this is unfortunate and makes working with `NonZero` types often not worth it, even if the operations you're doing are clearly sound. I've marked these as stable as I've been told in the past that trait impls are automatically stable. I'm happy to change it to unstable if this wasn't correct information. I'm not entirely confident what version I should have put down, so I followed https://www.whatrustisit.com. Hopefully it's correct for this. Apologies in advance if this has come up before, but I couldn't find it.
2020-04-20Use assoc float consts instead of module levelLinus Färnstrand-5/+4
2020-04-20Define module level int consts from assoc constsLinus Färnstrand-2/+2
2020-04-20Stop accessing module level int consts via crate::<Ty>Linus Färnstrand-1/+0
2020-04-16Dogfood or_patterns in the standard libraryJosh Stone-4/+4
2020-04-08Add inherent impls for unchecked math intrinsicsCAD97-0/+102
2020-04-05Make libcore float constant examples similar to libstdLinus Färnstrand-12/+4
2020-04-03Make documentation examples use new integer assoc constsLinus Färnstrand-3/+3
2020-04-03Rollup merge of #70708 - Pocakking:fix-ascii-case-conv-typo, r=sfacklerMazdak Farrokhzad-2/+2
Fix typo in u8::to_ascii_uppercase and u8::to_ascii_lowercase Corrects misspelling of fifth.
2020-04-02Fix typo in u8::to_ascii_uppercase and u8::to_ascii_lowercasePocakking-2/+2
fith => fifth
2020-03-29Stabilize float::to_int_uncheckedMark Rousskov-14/+10
This renames and stabilizes unsafe floating point to integer casts, which are intended to be the substitute for the currently unsound `as` behavior, once that changes to safe-but-slower saturating casts.
2020-03-26Rename asm! to llvm_asm!Amanieu d'Antras-2/+2
asm! is left as a wrapper around llvm_asm! to maintain compatibility.
2020-03-13update stable-since version for const_int_conversionTrevor Spiteri-12/+12
2020-03-11Rollup merge of #69373 - tspiteri:const_int_conversion, r=oli-obkMazdak Farrokhzad-16/+48
Stabilize const for integer {to,from}_{be,le,ne}_bytes methods All of these functions can be implemented simply and naturally as const functions, e.g. `u32::from_le_bytes` can be implemented as ```rust (bytes[0] as u32) | (bytes[1] as u32) << 8 | (bytes[2] as u32) << 16 | (bytes[3] as u32) << 24 ``` So stabilizing the constness will not expose that internally they are implemented using transmute which is not const in stable.
2020-03-07Implement BitOr and BitOrAssign for the NonZero integer typesThom Chiovoloni-0/+52
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.