Document default values for primitive types
All primitive types implement the `Default` trait but the documentation just says `Returns the "default value" for a type.` and doesn't give a hint about the actual default value. I think it would be good to document the default values in a proper way.
I changed the `default_impl` macro to accept a doc string as a third parameter and use this string to overwrite the documentation of `default()` for each primitive type.
The generated documentation now looks like this:
Disable big-endian simd in swap_nonoverlapping_bytes
This is a workaround for #42778, which was git-bisected to #40454's
optimizations to `mem::swap`, later moved to `ptr` in #42819. Natively
compiled rustc couldn't even compile stage1 libcore on powerpc64 and
s390x, but they work fine without this `repr(simd)`. Since powerpc64le
works OK, it seems probably related to being big-endian.
The underlying problem is not yet known, but this at least makes those
architectures functional again in the meantime.
cc @arielb1
Implement Eq/Hash/Debug etc. for unsized tuples.
As I mentioned in [the comment in #18469](https://github.com/rust-lang/rust/issues/18469#issuecomment-306767422), the implementations of `PartialEq`, `Eq`, `PartialOrd`, `Ord`, `Debug`, `Hash` can be generalized to unsized tuples.
This is consistent with the `derive` behavior for unsized structs.
```rust
#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Debug, Default, Hash)]
struct MyTuple<X, Y, Z: ?Sized>(X, Y, Z);
fn f(x: &MyTuple<i32, i32, [i32]>) {
x == x;
x < x;
println!("{:?}", x);
}
```
Questions:
- Need an RFC?
- Need a feature gate? I don't think it does because the unsized tuple coercion #42527 is feature-gated.
- I changed `builder.field($name);` into `builder.field(&$name);` in the `Debug` implementation to pass compilation. This won't affect the behavior because `Debug for &'a T` is a mere redirection to `Debug for T`. However, I don't know if it affects code size / performance.
This is a workaround for #42778, which was git-bisected to #40454's
optimizations to `mem::swap`, later moved to `ptr` in #42819. Natively
compiled rustc couldn't even compile stage1 libcore on powerpc64 and
s390x, but they work fine without this `repr(simd)`. Since powerpc64le
works OK, it seems probably related to being big-endian.
The underlying problem is not yet known, but this at least makes those
architectures functional again in the meantime.
cc @arielb1
Update docs for Debug* structs. #29355
This adds docs for the Debug* structs as well as examples from the
Formatter::debug_* methods, so that a user knows how to construct them.
I added these examples as the builders module is not public and hence
the debug_*_new() functions are not available to a user.
r? @steveklabnik
Delete deprecated & unstable range-specific `step_by`
Using the new one is annoying while this one exists, since the inherent method hides the one on iterator.
Tracking issue: #27741
Replacement: #41439
Deprecation: #42310 for 1.19
Fixes#41477
This adds docs for the Debug* structs as well as examples from the
Formatter::debug_* methods, so that a user knows how to construct them.
I added these examples as the builders module is not public and hence
the debug_*_new() functions are not available to a user.
r? @steveklabnik
Review comments.
Mainly adding in the links for all of the structs and functions.
Remove rust tag on code blocks.
Add `Iterator::for_each`
This works like a `for` loop in functional style, applying a closure to
every item in the `Iterator`. It doesn't allow `break`/`continue` like
a `for` loop, nor any other control flow outside the closure, but it may
be a more legible style for tying up the end of a long iterator chain.
This was tried before in #14911, but nobody made the case for using it
with longer iterators. There was also `Iterator::advance` at that time
which was more capable than `for_each`, but that no longer exists.
The `itertools` crate has `Itertools::foreach` with the same behavior,
but thankfully the names won't collide. The `rayon` crate also has a
`ParallelIterator::for_each` where simple `for` loops aren't possible.
> I really wish we had `for_each` on seq iterators. Having to use a
> dummy operation is annoying. - [@nikomatsakis][1]
[1]: https://github.com/nikomatsakis/rayon/pull/367#issuecomment-308455185
[libcore/cmp] Expand Ord/PartialOrd Derivable doc for enum types
Expand Derivable docblock section for `Ord` and `PartialOrd` to cover
`enum` types, in addition to the existing language explaining it for
`struct` types.
Update docs for fmt::write.
#29355
I reworded it slightly to make it more clear that the function only take
two arguments - the output and the Arguments struct that can be
generated from the format_args! macro.
r? @steveklabnik
Reuse the mem::swap optimizations to speed up slice::rotate
This is most helpful for compound types where LLVM didn't vectorize the loop. Highlight: bench slice::rotate_medium_by727_strings gets 38% faster.
Exposes the swapping logic from PR https://github.com/rust-lang/rust/pull/40454 as `pub unsafe fn ptr::swap_nonoverlapping` under library feature `swap_nonoverlapping` https://github.com/rust-lang/rust/issues/42818.
(The new method seemed plausible, and was the simplest way to share the logic. I'm not attached to it, though, so let me know if a different way would be better.)
Fix NaN handling in is_sign_negative/positive
This would be my proposed fix for the #42425 provided we decide it is indeed a problem.
Note this would technically be a breaking change to a stable API. We might want to consider deprecating these methods and adding new ones.
Expand Derivable docblock section for `Ord` and `PartialOrd` to cover
`enum` types, in addition to the existing language explaining it for
`struct` types.
