Add `Iterator::map_while`
In `Iterator` trait there is `*_map` version of [`filter`] — [`filter_map`], however, there is no `*_map` version of [`take_while`], that can also be useful.
### Use cases
In my code, I've found that I need to iterate through iterator of `Option`s, stopping on the first `None`. So I've written code like this:
```rust
let arr = [Some(4), Some(10), None, Some(3)];
let mut iter = arr.iter()
.take_while(|x| x.is_some())
.map(|x| x.unwrap());
assert_eq!(iter.next(), Some(4));
assert_eq!(iter.next(), Some(10));
assert_eq!(iter.next(), None);
assert_eq!(iter.next(), None);
```
Thit code
1) isn't clean
2) In theory, can generate bad bytecode (I'm actually **not** sure, but I think that `unwrap` would generate additional branches with `panic!`)
The same code, but with `map_while` (in the original PR message it was named "take_while_map"):
```rust
let arr = [Some(4), Some(10), None, Some(3)];
let mut iter = arr.iter().map_while(std::convert::identity);
```
Also, `map_while` can be useful when converting something (as in [examples]).
[`filter`]: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.filter
[`filter_map`]: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.filter_map
[`take_while`]: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.take_while
[examples]: https://github.com/rust-lang/rust/compare/master...WaffleLapkin:iter_take_while_map?expand=1#diff-7e57917f962fe6ffdfba51e4955ad6acR1042
Move numeric consts to associated consts step1
A subset of #67913. Implements the first step of RFC https://github.com/rust-lang/rfcs/pull/2700
This PR adds the new constants as unstable constants and defines the old ones in terms of the new ones. Then fix a tiny bit of code that started having naming collisions because of the new assoc consts.
Removed a test that did not seem relevant any longer. Since doing just `u8::MIN` should now indeed be valid.
Rename `Alloc` to `AllocRef`
The allocator-wg has decided to merge this change upstream in https://github.com/rust-lang/wg-allocators/issues/8#issuecomment-577122958.
This renames `Alloc` to `AllocRef` because types that implement `Alloc` are a reference, smart pointer, or ZSTs. It is not possible to have an allocator like `MyAlloc([u8; N])`, that owns the memory and also implements `Alloc`, since that would mean, that moving a `Vec<T, MyAlloc>` would need to correct the internal pointer, which is not possible as we don't have move constructors.
For further explanation please see https://github.com/rust-lang/wg-allocators/issues/8#issuecomment-489464843 and the comments after that one.
Additionally it clarifies the semantics of `Clone` on an allocator. In the case of `AllocRef`, it is clear that the cloned handle still points to the same allocator instance, and that you can free data allocated from one handle with another handle.
The initial proposal was to rename `Alloc` to `AllocHandle`, but `Ref` expresses the semantics better than `Handle`. Also, the only appearance of `Handle` in `std` are for windows specific resources, which might be confusing.
Blocked on https://github.com/rust-lang/miri/pull/1160
Stabilize ptr::slice_from_raw_parts[_mut]
Closes#36925, the tracking issue.
Initial impl: #60667
r? @rust-lang/libs
In addition to stabilizing, I've adjusted the example of `ptr::slice_from_raw_parts` to use `slice_from_raw_parts` instead of `slice_from_raw_parts_mut`, which was unnecessary for the example as written.
Add leading_ones and trailing_ones methods to the primitive integer types
I was surprised these were missing (given that `leading_zeros` and `trailing_zeros` exist), and they seem trivial and hopefully not controversial.
Note that there's some precedent in that `count_ones` and `count_zeros` are both supported even though only one of these has an intrinsic.
I'm not sure if these need a `rustc_const_unstable` flag (the tests don't seem to mind that it's missing). I just made them const, since there's not really any reason for these to be non-const when the `_zeros` variants are const.
Note: My understanding is trivial stuff like (hopefully) this can land without an RFC, but I'm not fully sure about the process though. Questions like "when does the tracking issue get filed?", are a total mystery to me. So, any guidance is appreciated, and sorry in advance if I should have gone through some more involved process for this.
Avoid overflow in `std::iter::Skip::count`
The call to `count` on the inner iterator can overflow even if `Skip` itself would return less that `usize::max_value()` items.
Fixes#68139
Rollup of 8 pull requests
Successful merges:
- #67734 (Remove appendix from Apache license)
- #67795 (Cleanup formatting code)
- #68290 (Fix some tests failing in `--pass check` mode)
- #68297 ( Filter and test predicates using `normalize_and_test_predicates` for const-prop)
- #68302 (Fix #[track_caller] and function pointers)
- #68339 (Add `riscv64gc-unknown-linux-gnu` into target list in build-manifest)
- #68381 (Added minor clarification to specification of GlobalAlloc::realloc.)
- #68397 (rustdoc: Correct order of `async` and `unsafe` in `async unsafe fn`s)
Failed merges:
r? @ghost
Added minor clarification to specification of GlobalAlloc::realloc.
The specification of `realloc` is slightly unclear:
```
/// * `layout` must be the same layout that was used
/// to allocate that block of memory,
```
https://github.com/rust-lang/rust/blob/master/src/libcore/alloc.rs#L541-L542
In the case of an `alloc` or `alloc_zeroed` this is fairly evidently the `layout` parameter passed into the original call. In the case of a `realloc`, this I assume is `layout` modified to contain `new_size`. However, I could not find this case specified in the documentation. Thus technically in a sequence of calls to `realloc`, it would be valid to provide the second call to `realloc` the same `layout` as the first call to `realloc`, which is almost certainly not going to be handled correctly.
This PR attempts to clarify the specification.
Stabilize ManuallyDrop::take
Tracking issue: closes#55422
FCP merge: https://github.com/rust-lang/rust/issues/55422#issuecomment-572653619
Reclaims the doc improvements from closed#62198.
-----
Stable version is a simple change if necessary.
Proposal: [relnotes] (this changes how to best take advantage of `ManuallyDrop`, esp. wrt. `Drop::drop` and finalize-by-value members)
These are only called from one place and don't generally support being called
from other places; furthermore, they're the only formatter functions that look
at the `args` field (which a future commit will remove).
Remove real_drop_in_place
In af9b057156, I added `real_drop_in_place` because Stacked Borrows at the time couldn't handle transmuting of mutable references to raw pointers and back. Stacked Borrows 2, however, doesn't have any issue with these transmutes, so it is time to remove this hack again.
Make iter::Empty<T> Send and Sync for any T
Continuing from #57682
It's quite funny, when I initially submitted this pull request, I said "Likely nobody will be using that property of `iter::empty`", but then a year later I got a compilation error because it wasn't `Send` and `Sync`.
Unfortunately, `PhantomData<fn() -> T>` still errors out. Oh well. I proposed `
struct PhantomFnWorkaround<T>(fn() -> T);`, but dtolnay did not like it, so using explicit implementations.
Implement `DebugStruct::non_exhaustive`.
This patch adds a function (finish_non_exhaustive) to add ellipsis before the closing brace when formatting using `DebugStruct`.
## Example
```rust
#![feature(debug_non_exhaustive)]
use std::fmt;
struct Bar {
bar: i32,
hidden: f32,
}
impl fmt::Debug for Bar {
fn fmt(&self, fmt: &mut fmt::Formatter<'_>) -> fmt::Result {
fmt.debug_struct("Bar")
.field("bar", &self.bar)
.non_exhaustive(true) // Show that some other field(s) exist.
.finish()
}
}
assert_eq!(
format!("{:?}", Bar { bar: 10, hidden: 1.0 }),
"Bar { bar: 10, .. }",
);
```
