Improve the docs for the write and writeln macros
This change reduces duplication by linking the documentation for
`writeln!` to `write!`. It also restructures the `write!` documentation
to read in a more logical manner (I hope; feedback would be welcome).
Updates #29329, #29381
Implement all PartialOrd methods for Reverse
When making a forwarding wrapper we must in general forward all methods,
so that we use the type's own `lt` for example instead of the default.
Example important case: f32's partial_cmp does several operations but
its lt is a primitive.
Follow up on #40720
This change reduces duplication by linking the documentation for
`writeln!` to `write!`. It also restructures the `write!` documentation
to read in a more logical manner.
Updates #29329, #29381
When making a forwarding wrapper we must in general forward all methods,
so that we use the type's own `lt` for example instead of the default.
Example important case: f32's partial_cmp does several operations but
its lt is a primitive.
libcore: fix compilation on 16bit target (MSP430).
Since PR #40601 has been merged, libcore no longer compiles on MSP430.
The reason is this code in `break_patterns`:
```rust
let mut random = len;
random ^= random << 13;
random ^= random >> 17;
random ^= random << 5;
random &= modulus - 1;
```
It assumes that `len` is at least a 32 bit integer.
As a workaround replace `break_patterns` with an empty function for 16bit targets.
cc @stjepang
cc @alexcrichton
Added core::cmp::Reverse for sort_by_key reverse sorting
I'm not sure if this is the best way to go about proposing this feature but it's pretty useful. It allows you to use `sort_by_key` and return tuples where a single item is then reversed to how it normally sorts.
I quite miss something like this in Rust currently though I'm not sure if this is the best way to implement it.
libcore: fix compilation on 16bit target (MSP430).
Since PR #40601 has been merged, libcore no longer compiles on MSP430.
The reason is this code in `break_patterns`:
```rust
let mut random = len;
random ^= random << 13;
random ^= random >> 17;
random ^= random << 5;
random &= modulus - 1;
```
It assumes that `len` is at least a 32 bit integer.
As a workaround replace `break_patterns` with an empty function for 16bit targets.
cc @stjepang
cc @alexcrichton
Link ParseBoolError to from_str method of bool
Referencing task in #29375. Sorry for not opening another branch on my fork for this. Was working on this early this morning and forgot to branch off master
Optimize insertion sort
This change slightly changes the main iteration loop so that LLVM can optimize it more efficiently.
Benchmark:
```
name before ns/iter after ns/iter diff ns/iter diff %
slice::sort_unstable_small_ascending 39 (2051 MB/s) 38 (2105 MB/s) -1 -2.56%
slice::sort_unstable_small_big_random 579 (2210 MB/s) 575 (2226 MB/s) -4 -0.69%
slice::sort_unstable_small_descending 80 (1000 MB/s) 70 (1142 MB/s) -10 -12.50%
slice::sort_unstable_small_random 396 (202 MB/s) 386 -10 -2.53%
```
The benchmark is not a fluke. I can see that performance on `small_descending` is consistently better after this change. I'm not 100% sure why this makes things faster, but my guess would be that `v.len()+1` to the compiler looks like it could in theory overflow.
