RFC 2070 part 1: PanicInfo and Location API changes
This implements part of https://rust-lang.github.io/rfcs/2070-panic-implementation.html
Tracking issue: https://github.com/rust-lang/rust/issues/44489
* Move `std::panic::PanicInfo` and `std::panic::Location` to a new `core::panic` module. The two types and the `std` module were already `#[stable]` and stay that way, the new `core` module is `#[unstable]`.
* Add a new `PanicInfo::message(&self) -> Option<&fmt::Arguments>` method, which is `#[unstable]`.
* Implement `Display` for `PanicInfo` and `Location`
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.
#37653 support `default impl` for specialization
this commit implements the second part of the `default impl` feature:
> - a `default impl` need not include all items from the trait
> - a `default impl` alone does not mean that a type implements the trait
The first point allows rustc to compile and run something like this:
```
trait Foo {
fn foo_one(&self) -> &'static str;
fn foo_two(&self) -> &'static str;
}
default impl<T> Foo for T {
fn foo_one(&self) -> &'static str {
"generic"
}
}
struct MyStruct;
fn main() {
assert!(MyStruct.foo_one() == "generic");
}
```
but it shows a proper error if trying to call `MyStruct.foo_two()`
The second point allows a `default impl` to be considered as not implementing the `Trait` if it doesn't implement all the trait items.
The tests provided (in the compile-fail section) should cover all the possible trait resolutions.
Let me know if some tests is missed.
See [referenced ](https://github.com/rust-lang/rust/issues/37653) issue for further info
r? @nikomatsakis
Clarified why `Sized` bound not implicit on trait's implicit `Self` type.
This part of the documentation was a little confusing to me on first read. I've added a couple lines for further explanation. Hopefully this makes things a bit clearer for new readers.
Add std/core::iter::repeat_with
Adds an iterator primitive `repeat_with` which is the "lazy" version of `repeat` but also more flexible since you can build up state with the `FnMut`. The design is mostly taken from `repeat`.
r? @rust-lang/libs
cc @withoutboats, @scottmcm
Update ops range example to avoid confusion between indexes and values.
Makes clearer the numbers in the range refer to indexes, not the values at those indexes.
Correct a few stability attributes
* `core_float_bits`, `duration_core`, `path_component_asref`, and `repr_align` were stabalized in 1.25.0 not 1.24.0.
* Impls for `NonNull` involving unstable things should remain unstable.
* `Duration` should remain stable since 1.3.0 so it appears correctly in the `std` docs.
* `cursor_mut_vec` is an impl on only stable things so should be marked stable.
Add Range[Inclusive]::is_empty
During https://github.com/rust-lang/rfcs/pull/1980, it was discussed that figuring out whether a range is empty was subtle, and thus there should be a clear and obvious way to do it. It can't just be ExactSizeIterator::is_empty (also unstable) because not all ranges are ExactSize -- such as `Range<i64>` and `RangeInclusive<usize>`.
Things to ponder:
- Unless this is stabilized first, this makes stabilizing ExactSizeIterator::is_empty more icky, since this hides that.
- This is only on `Range` and `RangeInclusive`, as those are the only ones where it's interesting. But one could argue that it should be on more for consistency, or on RangeArgument instead.
- The bound on this is PartialOrd, since that works ok (see tests for float examples) and is consistent with `contains`. But ranges like `NAN..=NAN`_are_ kinda weird.
- [x] ~~There's not a real issue number on this yet~~
Document the behaviour of infinite iterators on potentially-computable methods
It’s not entirely clear from the current documentation what behaviour
calling a method such as `min` on an infinite iterator like `RangeFrom`
is. One might expect this to terminate, but in fact, for infinite
iterators, `min` is always nonterminating (at least in the standard
library). This adds a quick note about this behaviour for clarification.
Add fetch_nand to atomics
I think this is all fine but I have little familiarity with the atomic code (or libcore in general) so I may have accidentally done something wrong here...
cc #13226 (the tracking issue)
