| Age | Commit message (Collapse) | Author | Lines |
|
Stabilizes
* `<&mut str>::as_bytes_mut`
* `<Box<str>>::into_boxed_bytes`
* `std::str::from_boxed_utf8_unchecked`
* `std::str::from_utf8_mut`
* `std::str::from_utf8_unchecked_mut`
Closes #41119
|
|
Stabilizes:
* `compile_error!` as a macro defined by rustc
Closes #40872
|
|
Stabilizes
* `core::mem::ManuallyDrop`
* `std::mem::ManuallyDrop`
* `ManuallyDrop::new`
* `ManuallyDrop::into_inner`
* `ManuallyDrop::drop`
* `Deref for ManuallyDrop`
* `DerefMut for ManuallyDrop`
Closes #40673
|
|
Stabilizes:
* `Utf8Error::error_len`
Closes #40494
|
|
Stabilized
* `<str>::get`
* `<str>::get_mut`
* `<str>::get_unchecked`
* `<str>::get_unchecked_mut`
Closes #39932
|
|
Stabilized:
* `Option::get_or_insert`
* `Option::get_or_insert_with`
Closes #39288
|
|
Stabilizes:
* `<char>::escape_debug`
* `std::char::EscapeDebug`
Closes #35068
|
|
|
|
zackmdavis:missing_sum_and_product_for_128_bit_integers, r=nagisa
add u128/i128 to sum/product implementors
Resolves #43235.
|
|
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
|
|
Resolves #43235.
|
|
`position` could not be implemented because calling `rposition`
on the inner iterator would require more trait bounds.
|
|
These are overridden by slice::Iter
|
|
Correct some stability attributes
These show up in rustdoc so need to be correct.
|
|
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.
|
|
Add hint about the return code of panic!
I hope the link works on all cases, since the `unreachable` doc is copied to `std::` as well.
|
|
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
|
|
These show up in rustdoc so need to be correct.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add a stability marker for core::cmp::Reverse.0
Closes #43027
|
|
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
|
|
Closes #43027
|
|
Stabilize feature sort_unstable
Closes #40585
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Replacement: 41439
Deprecation: 42310 for 1.19
Fixes 41477
|
|
|
|
|
|
Revert "Stabilize RangeArgument"
This reverts commit 143206d54d7558c2326212df99efc98110904fdb.
From the discussion in #30877 it seems like this is premature.
|
|
This reverts commit 143206d54d7558c2326212df99efc98110904fdb.
|
|
|
|
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
|