| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This reverts commit e53a2a72743810e05f58c61c9d8a4c89b712ad2e.
|
|
|
|
portability lint
https://github.com/rust-lang/rust/pull/49305#issuecomment-376293243
|
|
Tracking issue: https://github.com/rust-lang/rust/issues/33417
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
replace `convert::Infallible` with `!`
|
|
|
|
|
|
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
|
|
Fixes #27730
|
|
|
|
RFC: https://github.com/rust-lang/rfcs/pull/2307
|
|
|
|
|
|
Add a potential cause raising `ParseIntError`.
Initially, I wanted to add it directly to the documentation of `str. parse()` method, I finally found that it was more relevant (I hope so?) to directly document the structure in question. I've added a scenario, in which we could all get caught at least once, to make it easier to diagnose the problem when parsing integers.
|
|
|
|
|
|
|
|
The error was:
```
[00:05:25] tidy error: /checkout/src/libcore/num/mod.rs:3848: trailing whitespace
[00:05:25] tidy error: /checkout/src/libcore/num/mod.rs:3851: line longer than 100 chars
[00:05:25] tidy error: /checkout/src/libcore/num/mod.rs:3851: trailing whitespace
[00:05:26] some tidy checks failed
```
The line was truncated to 92 characters.
|
|
Initially, I wanted to add it directly to the documentation of `str. parse()' method, I finally found that it was more relevant (I hope so?) to directly document the structure in question. I've added a scenario, in which we could all get caught at least once, to make it easier to diagnose the problem when parsing integers.
|
|
Add non-panicking variants of pow for integer types
Currently, calling pow may panic in case of overflow, and the function does not have non-panicking counterparts. Thus, it would be beneficial to add those in.
Closes #48291.
Relevant tracking issue: #48320
|
|
Make ".e0" not parse as 0.0
This forces floats to have either a digit before the separating point, or after. Thus `".e0"` is invalid like `"."`, when using `parse()`. Fixes #40654. As mentioned in the issue, this is technically a breaking change... but clearly incorrect behaviour at present.
|
|
|
|
Current document takes 2^4, which is equal to 4^2.
This example is not very helpful for those unfamiliar with math words in English and thus rely on example codes.
|
|
This forces floats to have either a digit before the separating point, or after. Thus ".e0" is invalid like ".", when using `parse()`.
|
|
Currently, calling pow may panic in case of overflow, and the function
does not have non-panicking counterparts. Thus, it would be beneficial
to add those in.
|
|
Primitive docs relevant
This fixes the documentation to show the right types in the examples for many integer methods.
I need to check if the result is correct before we merge.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The current `f32|f64.to_degrees` implementation uses a division to calculate 180/π, which causes a loss of precision. Using a constant is still not perfect (implementing a maximally-precise algorithm would come with a high performance cost), but improves precision with a minimal change.
|
|
Expose float from_bits and to_bits in libcore.
These methods have no dependencies on libm and thus should be offered in libcore.
|
|
doc: improve None condition doc for `checked_div` and `checked_rem`
This commit improves the condition mentioned in the docs for which `checked_div` and `checked_rem` return `None`.
For signed division, the commit changes "the operation results in overflow" to "the division results in overflow", otherwise there is room for misinterpretation for `checked_rem`: Without considering overflow, `MIN % -1` would be simply zero, allowing the misinterpretation that "the operation" does not result in overflow in this case. This ambiguity is removed using "when the division results in overflow".
For unsigned division, the condition for `None` should be simply when `rhs == 0`, as no other overflow is possible.
|
|
Swapping the conditions generates more efficient x86 assembly. See
https://github.com/rust-lang/rust/pull/46926#issuecomment-354567412.
|
|
Add "Basic Usage" to int min_value and max_value docs
This adds "Basic Usage:" to the docs of `min_value` and `max_value`, which makes it consistent with docs of other integer methods.
|
|
Make core::f32/f64 docs match std.
For some reason these weren't in sync.
|
|
|
|
|
|
|
|
|
