Make `ParseIntError` and `IntErrorKind` fully public
Why would you write nice error types if I can't read them?
# Why
It can be useful to use `match` with errors produced when parsing strings to int. This would be useful for the `.err_match()` function in my [new crate](https://crates.io/crates/read_input).
---
I could also do this for `ParseFloatError` if people think it is a good idea.
I am new around hear so please tell me if I am getting anything wrong.
Add std::iter::unfold
This adds an **unstable** ~`std::iter::iterate`~ `std::iter::unfold` function and ~`std::iter::Iterate`~ `std::iter::Unfold` type that trivially wrap a ~`FnMut() -> Option<T>`~ `FnMut(&mut State) -> Option<T>` closure to create an iterator. ~Iterator state can be kept in the closure’s environment or captures.~
This is intended to help reduce amount of boilerplate needed when defining an iterator that is only created in one place. Compare the existing example of the `std::iter` module: (explanatory comments elided)
```rust
struct Counter {
count: usize,
}
impl Counter {
fn new() -> Counter {
Counter { count: 0 }
}
}
impl Iterator for Counter {
type Item = usize;
fn next(&mut self) -> Option<usize> {
self.count += 1;
if self.count < 6 {
Some(self.count)
} else {
None
}
}
}
```
… with the same algorithm rewritten to use this new API:
```rust
fn counter() -> impl Iterator<Item=usize> {
std::iter::unfold(0, |count| {
*count += 1;
if *count < 6 {
Some(*count)
} else {
None
}
})
}
```
-----
This also add unstable `std::iter::successors` which takes an (optional) initial item and a closure that takes an item and computes the next one (its successor).
```rust
let powers_of_10 = successors(Some(1_u16), |n| n.checked_mul(10));
assert_eq!(powers_of_10.collect::<Vec<_>>(), &[1, 10, 100, 1_000, 10_000]);
```
Return &T / &mut T in ManuallyDrop Deref(Mut) impl
Without this change the generated documentation looks like this:
fn deref(&self) -> &<ManuallyDrop<T> as Deref>::Target
Returning the actual type directly makes the generated docs more clear:
fn deref(&self) -> &T
Basically, compare how the impl for `Box<T>` and `ManuallyDrop<T>` looks in this screenshot:
Doc total order requirement of sort(_unstable)_by
I took the definition of what a total order is from the Ord trait
docs. I specifically put "elements of the slice" because if you
have a slice of f64s, but know none are NaN, then sorting by
partial ord is total in this case. I'm not sure if I should give
such an example in the docs or not.
r? @GuillaumeGomez
Revert #51601Closes: #55985
Specialization of `StepBy<Range(Inclusive)>` results in an incorrectly behaving code when `step_by` is combined with `skip` or `nth`.
If this will get merged we probably should reopen issues previously closed by #51601 (if there was any).
avoid shared ref in UnsafeCell::get
Avoid taking a shared reference in `UnsafeCell::get`. This *should* be taking a raw reference (see https://github.com/rust-lang/rfcs/pull/2582), but that operation is not currently available, so I propose we exploit `repr(transparent)` instead and cast the pointer around.
This is required to make `UnsafeCell::get` pass the [stacked borrows implementation](https://www.ralfj.de/blog/2018/11/16/stacked-borrows-implementation.html) in miri (currently, `UnsafeCell::get` is on a whitelist, but that is of course not very satisfying). It shouldn't affect normal execution/codegen. Would be great if we could get this landed and shrink miri's whitelist!
Cc @nikomatsakis
core/tests/num: Simplify `test_int_from_str_overflow()` test code
This commit changes the test code to compare against easier-to-read, static values instead of relying on the result of `wrapping_add()` which may or may not result in the value that we expect.
core/char: Speed up `to_digit()` for `radix <= 10`
I noticed that `char::to_digit()` seemed to do a bit of extra work for handling `[a-zA-Z]` characters. Since `to_digit(10)` seems to be the most common case (at least in the `rust` codebase) I thought it might be valuable to create a fast path for that case, and according to the benchmarks that I added in one of the commits it seems to pay off. I also created another fast path for the `radix < 10` case, which also seems to have a positive effect.
It is very well possible that I'm measuring something entirely unrelated though, so please verify these numbers and let me know if I missed something!
### Before
```
# Run 1
test char::methods::bench_to_digit_radix_10 ... bench: 16,265 ns/iter (+/- 1,774)
test char::methods::bench_to_digit_radix_16 ... bench: 13,938 ns/iter (+/- 2,479)
test char::methods::bench_to_digit_radix_2 ... bench: 13,090 ns/iter (+/- 524)
test char::methods::bench_to_digit_radix_36 ... bench: 14,236 ns/iter (+/- 1,949)
# Run 2
test char::methods::bench_to_digit_radix_10 ... bench: 16,176 ns/iter (+/- 1,589)
test char::methods::bench_to_digit_radix_16 ... bench: 13,896 ns/iter (+/- 3,140)
test char::methods::bench_to_digit_radix_2 ... bench: 13,158 ns/iter (+/- 1,112)
test char::methods::bench_to_digit_radix_36 ... bench: 14,206 ns/iter (+/- 1,312)
# Run 3
test char::methods::bench_to_digit_radix_10 ... bench: 16,221 ns/iter (+/- 2,423)
test char::methods::bench_to_digit_radix_16 ... bench: 14,361 ns/iter (+/- 3,926)
test char::methods::bench_to_digit_radix_2 ... bench: 13,097 ns/iter (+/- 671)
test char::methods::bench_to_digit_radix_36 ... bench: 14,388 ns/iter (+/- 1,068)
```
### After
```
# Run 1
test char::methods::bench_to_digit_radix_10 ... bench: 11,521 ns/iter (+/- 552)
test char::methods::bench_to_digit_radix_16 ... bench: 12,926 ns/iter (+/- 684)
test char::methods::bench_to_digit_radix_2 ... bench: 11,266 ns/iter (+/- 1,085)
test char::methods::bench_to_digit_radix_36 ... bench: 14,213 ns/iter (+/- 614)
# Run 2
test char::methods::bench_to_digit_radix_10 ... bench: 11,424 ns/iter (+/- 1,042)
test char::methods::bench_to_digit_radix_16 ... bench: 12,854 ns/iter (+/- 1,193)
test char::methods::bench_to_digit_radix_2 ... bench: 11,193 ns/iter (+/- 716)
test char::methods::bench_to_digit_radix_36 ... bench: 14,249 ns/iter (+/- 3,514)
# Run 3
test char::methods::bench_to_digit_radix_10 ... bench: 11,469 ns/iter (+/- 685)
test char::methods::bench_to_digit_radix_16 ... bench: 12,852 ns/iter (+/- 568)
test char::methods::bench_to_digit_radix_2 ... bench: 11,275 ns/iter (+/- 1,356)
test char::methods::bench_to_digit_radix_36 ... bench: 14,188 ns/iter (+/- 1,501)
```
I ran the benchmark using:
```sh
python x.py bench src/libcore --stage 1 --keep-stage 0 --test-args "bench_to_digit"
```
Add mem::forget_unsized() for forgetting unsized values
~~Allows passing values of `T: ?Sized` types to `mem::drop` and `mem::forget`.~~
Adds `mem::forget_unsized()` that accepts `T: ?Sized`.
I had to revert the PR that removed the `forget` intrinsic and replaced it with `ManuallyDrop`: https://github.com/rust-lang/rust/pull/40559
We can't use `ManuallyDrop::new()` here because it needs `T: Sized` and we don't have support for unsized return values yet (will we ever?).
r? @eddyb
Add link to std::mem::size_of to size_of intrinsic documentation
The other intrinsics with safe/stable alternatives already have documentation to this effect.
This commit changes the test code to compare against easier-to-read, static values instead of relying on the result of `wrapping_add()` which may or may not result in the value that we expect.
