Implement Integer methods for Wrapping
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
Improve documentation for Borrow
This is the first step in improving the documentation for all the reference conversion traits. It proposes new text for the trait documentation of `Borrow`. Since I feel it is a somewhat radical rewrite and includes a stricter contract for `Borrow` then the previous text—namely that *all* shared traits need to behave the same, not just a select few—, I wanted to get some feedback before continuing.
Apart from the ‘normative’ description, the new text also includes a fairly extensive explanation of how the trait is used in the examples section. I included it because every time I look at how `HashMap` uses the trait, I need to think for a while as the use is a bit twisted. So, I thought having this thinking written down as part of the trait itself might be useful. One could argue that this should go into The Book, and, while I really like having everything important in the docs, I can see the text moved there, too.
So, before I move on: is this new text any good? Do we feel it is correct, useful, comprehensive, and understandable?
(This PR is in response to #44868 and #24140.)
The expected behavior is that the environment's PATH should be used
to find the process. posix_spawn() could be used if we iterated
PATH to search for the binary to execute. For now just skip
posix_spawn() if PATH is modified.
Cleanup metadata and incremental cache processing of constants
fixes#49033fixes#49081
we really need tests for this. do we have any cross compilation tests? I couldn't find any
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
Add hexadecimal formatting of integers with fmt::Debug
This can be used for integers within a larger types which implements Debug (possibly through derive) but not fmt::UpperHex or fmt::LowerHex.
```rust
assert!(format!("{:02x?}", b"Foo\0") == "[46, 6f, 6f, 00]");
assert!(format!("{:02X?}", b"Foo\0") == "[46, 6F, 6F, 00]");
```
RFC: https://github.com/rust-lang/rfcs/pull/2226
The new formatting string syntax (`x?` and `X?`) is insta-stable in this PR because I don’t know how to change a built-in proc macro’s behavior based of a feature gate. I can look into adding that, but I also strongly suspect that keeping this feature unstable for a time period would not be useful as possibly no-one would use it during that time.
This PR does not add the new (public) `fmt::Formatter` proposed in the API because:
* There was some skepticism on response to this part of the RFC
* It is not possible to implement as-is without larger changes to `fmt`, because `Formatter` at the moment has no easy way to tell apart for example `Octal` from `Binary`: it only has a function pointer for the relevant `fmt()` method.
If some integer-like type outside of `std` want to implement this behavior, another RFC will likely need to propose a different public API for `Formatter`.
Try to reduce amount of time on the asmjs builder
This PR has two commits for two separate strategies:
* First it disables optimizations for all tests, hopefully saving time by not optimizing the test code. This caused a number of run-pass tests to fail which are switched to being ignored here.
* Next it disables a number of test suites which aren't asm.js specific and already run elsewhere
cc #48826
