| Age | Commit message (Collapse) | Author | Lines | |
|---|---|---|---|---|
| 2020-05-19 | Rollup merge of #71886 - t-rapp:tr-saturating-funcs, r=dtolnay | Dylan 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-16 | Rollup merge of #72224 - lzutao:links, r=Dylan-DPC | Dylan DPC | -8/+8 | |
| doc: add links to rotate_(left|right) | ||||
| 2020-05-15 | Auto merge of #69659 - CAD97:step-rework-take-3, r=Amanieu | bors | -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-15 | doc: add links to rotate_(left|right) | Lzu Tao | -8/+8 | |
| 2020-05-10 | doc: minus (U+2212) instead of dash (U+002D) for negative infinity | Trevor Spiteri | -2/+2 | |
| 2020-05-05 | Rollup merge of #71845 - steveklabnik:add-const-examples, r=dtolnay | Dylan 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-04 | Stabilize saturating_abs and saturating_neg | Tobias Rapp | -6/+4 | |
| Stabilizes the following signed integer functions with saturation mechanics: * saturating_abs() * saturating_neg() Closes #59983 | ||||
| 2020-05-04 | Use f64 in f64 examples | Steve 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-04 | Add examples to int macros | Steve Klabnik | -2/+24 | |
| 2020-05-04 | f64 examples | Steve Klabnik | -0/+147 | |
| 2020-05-04 | correct -> intended | Steve Klabnik | -14/+14 | |
| 2020-05-04 | add some whitespace | Steve Klabnik | -0/+7 | |
| 2020-05-04 | Add examples for std::f32 constants. | Steve Klabnik | -0/+140 | |
| And also point people to use the associated constants of f32 instead. | ||||
| 2020-04-26 | Fix since attribute for nonzero_bitor impl's | Jonas Platte | -5/+5 | |
| 2020-04-25 | Rollup merge of #69813 - thomcc:nonzero-bitor, r=Amanieu | Dylan 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-20 | Use assoc float consts instead of module level | Linus Färnstrand | -5/+4 | |
| 2020-04-20 | Define module level int consts from assoc consts | Linus Färnstrand | -2/+2 | |
| 2020-04-20 | Stop accessing module level int consts via crate::<Ty> | Linus Färnstrand | -1/+0 | |
| 2020-04-16 | Dogfood or_patterns in the standard library | Josh Stone | -4/+4 | |
| 2020-04-08 | Add inherent impls for unchecked math intrinsics | CAD97 | -0/+102 | |
| 2020-04-05 | Make libcore float constant examples similar to libstd | Linus Färnstrand | -12/+4 | |
| 2020-04-03 | Make documentation examples use new integer assoc consts | Linus Färnstrand | -3/+3 | |
| 2020-04-03 | Rollup merge of #70708 - Pocakking:fix-ascii-case-conv-typo, r=sfackler | Mazdak Farrokhzad | -2/+2 | |
| Fix typo in u8::to_ascii_uppercase and u8::to_ascii_lowercase Corrects misspelling of fifth. | ||||
| 2020-04-02 | Fix typo in u8::to_ascii_uppercase and u8::to_ascii_lowercase | Pocakking | -2/+2 | |
| fith => fifth | ||||
| 2020-03-29 | Stabilize float::to_int_unchecked | Mark 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-26 | Rename asm! to llvm_asm! | Amanieu d'Antras | -2/+2 | |
| asm! is left as a wrapper around llvm_asm! to maintain compatibility. | ||||
| 2020-03-13 | update stable-since version for const_int_conversion | Trevor Spiteri | -12/+12 | |
| 2020-03-11 | Rollup merge of #69373 - tspiteri:const_int_conversion, r=oli-obk | Mazdak 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-07 | Implement BitOr and BitOrAssign for the NonZero integer types | Thom Chiovoloni | -0/+52 | |
| 2020-03-04 | Auto merge of #68952 - faern:stabilize-assoc-int-consts, r=dtolnay | bors | -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-26 | Rollup merge of #69209 - Mark-Simulacrum:strip-unsafe, r=dtolnay | Dylan DPC | -17/+15 | |
| Miscellaneous cleanup to formatting Each commit stands alone. This pull request will also resolve #58320. | ||||
| 2020-02-26 | use unions instead of transmute and add const safety comments | Trevor Spiteri | -8/+36 | |
| 2020-02-22 | Rollup merge of #68984 - ecstatic-morse:const-u8-is-ascii, r=sfackler | Dylan 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-22 | Stabilize const for integer {to,from}_{be,le,ne}_bytes methods | Trevor Spiteri | -12/+16 | |
| All of these functions can be implemented simply and naturally as const functions, e.g. u32::from_le_bytes can be implemented as (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-02-20 | Rollup merge of #68978 - ecstatic-morse:const-int-pow, r=oli-obk | Dylan 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-17 | Drop unused argument to float functions | Mark Rousskov | -2/+0 | |
| 2020-02-16 | Stabilize {f32, f64}::{LOG2_10, LOG10_2} | LeSeulArtichaut | -4/+4 | |
| 2020-02-15 | Formatter::sign is &'static str | Mark 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-12 | Add usage recommendation to old float constants | Linus Färnstrand | -0/+28 | |
| 2020-02-12 | Update float documentation to use associated consts | Linus Färnstrand | -22/+2 | |
| 2020-02-12 | Add notice about using new consts in new code on int modules | Linus Färnstrand | -0/+36 | |
| 2020-02-12 | Add notice about using new consts in new code on float modules | Linus Färnstrand | -0/+6 | |
| 2020-02-12 | Remove uint_macros that was identical to int_macros | Linus Färnstrand | -41/+13 | |
| 2020-02-12 | Replace min/max_value() with MIN/MAX in integer docs | Linus Färnstrand | -52/+52 | |
| 2020-02-12 | Use new preferred consts in int docs | Linus Färnstrand | -35/+13 | |
| 2020-02-12 | Add "soft deprecation" notice to old MIN/MAX docs | Linus Färnstrand | -12/+41 | |
| 2020-02-12 | Add "soft deprecation" notice to old min/max_value() docs | Linus Färnstrand | -40/+60 | |
| 2020-02-12 | Stabilize assoc_int_consts | Linus Färnstrand | -36/+32 | |
| 2020-02-10 | Rollup merge of #68986 - ecstatic-morse:const-ascii-ctype, r=Centril | Dylan 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-08 | Make `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. | ||||
 |
index : rust | |
| https://github.com/rust-lang/rust |
| about summary refs log tree commit diff |