This commit introduces 2 methods - `Option::zip` and `Option::zip_with` with
respective signatures:
- zip: `(Option<T>, Option<U>) -> Option<(T, U)>`
- zip_with: `(Option<T>, Option<U>, (T, U) -> R) -> Option<R>`
Both are under the feature gate "option_zip".
I'm not sure about the name "zip", maybe we can find a better name for this.
(I would prefer `union` for example, but this is a keyword :( )
--------------------------------------------------------------------------------
Recently in a russian rust begginers telegram chat a newbie asked (translated):
> Are there any methods for these conversions:
>
> 1. `(Option<A>, Option<B>) -> Option<(A, B)>`
> 2. `Vec<Option<T>> -> Option<Vec<T>>`
>
> ?
While second (2.) is clearly `vec.into_iter().collect::<Option<Vec<_>>()`, the
first one isn't that clear.
I couldn't find anything similar in the `core` and I've come to this solution:
```rust
let tuple: (Option<A>, Option<B>) = ...;
let res: Option<(A, B)> = tuple.0.and_then(|a| tuple.1.map(|b| (a, b)));
```
However this solution isn't "nice" (same for just `match`/`if let`), so I thought
that this functionality should be in `core`.
Fix bugs in Peekable and Flatten when using non-fused iterators
I fixed a couple of bugs with regard to the `Peekable` and `Flatten`/`FlatMap` iterators when the underlying iterator isn't fused. For testing, I also added a `NonFused` iterator wrapper that panics when `next` or `next_back` is called on an iterator that has returned `None` before, which will hopefully make it easier to spot these mistakes in the future.
### Peekable
`Peekable::next_back` was implemented as
```rust
self.iter.next_back().or_else(|| self.peeked.take().and_then(|x| x))
```
which is incorrect because when the `peeked` field is `Some(None)`, then `None` has already been returned from the inner iterator and what it returns from `next_back` can no longer be relied upon. `test_peekable_non_fused` tests this.
### Flatten
When a `FlattenCompat` instance only has a `backiter` remaining (i.e. `self.frontiter` is `None` and `self.iter` is empty), then `next` will call `self.iter.next()` every time, so the `iter` field needs to be fused. I fixed it by giving it the type `Fuse<I>` instead of `I`, I think this is the only way to fix it. `test_flatten_non_fused_outer` tests this.
Furthermore, previously `FlattenCompat::next` did not set `self.frontiter` to `None` after it returned `None`, which is incorrect when the inner iterator type isn't fused. I just delegated it to `try_fold` because that already handles it correctly. `test_flatten_non_fused_inner` tests this.
r? @scottmcm
submodules: update clippy from 8485d40a to d556bb73
Changes:
````
rustup https://github.com/rust-lang/rust/pull/68944
rustup https://github.com/rust-lang/rust/pull/69589/
Rustup to rust-lang/rust#69076
Don't convert Path to lossy str
Use `into_path`
Use pattern matching instead of manually checking condition
Fix typo
Remove git2 dependency.
Document that wildcard_imports doesn't warn about `use ...::prelude::*;`
Change changelog formatting
Update changelog_update doc to reflect the actual ordering of the changelog
Update CHANGELOG.md
````
Fixes#70007
Rollup of 7 pull requests
Successful merges:
- #68746 (Make macro metavars respect (non-)hygiene)
- #69688 (Move tidy check to mingw-check)
- #69735 (bootstrap: Use hash to determine if sanitizers needs to be rebuilt)
- #69922 (implement zeroed and uninitialized with MaybeUninit)
- #69956 (Ensure HAS_FREE_LOCAL_NAMES is set for ReFree)
- #70061 (Cosmetic fixes in documentation)
- #70064 (Update books)
Failed merges:
r? @ghost
Ensure HAS_FREE_LOCAL_NAMES is set for ReFree
This fixes a bug introduced by #69469.
I don't have any ideas on how to reate a regression test for this.
bootstrap: Use hash to determine if sanitizers needs to be rebuilt
* Rebuild sanitizers runtimes when LLVM submodule commit changes.
* When rebuilding LLVM / sanitizers, remove the stamp file before
starting the build process to invalidate previous build output.
Rollup of 7 pull requests
Successful merges:
- #69811 (resolve: Print import chains on privacy errors)
- #69870 (expand: Implement something similar to `#[cfg(accessible(path))]`)
- #69881 (VariantSizeDifferences: bail on SizeOverflow)
- #70000 (resolve: Fix regression in resolution of raw keywords in paths)
- #70029 (Bump the bootstrap compiler)
- #70046 (Use sublice patterns to avoid computing the len)
- #70049 (Fiddle `ParamEnv` through to a place that used to use `ParamEnv::empty` in a buggy manner)
Failed merges:
r? @ghost
expand: Implement something similar to `#[cfg(accessible(path))]`
cc https://github.com/rust-lang/rust/issues/64797
The feature is implemented as a `#[cfg_accessible(path)]` attribute macro rather than as `#[cfg(accessible(path))]` because it needs to wait until `path` becomes resolvable, and `cfg` cannot wait, but macros can wait.
Later we can think about desugaring or not desugaring `#[cfg(accessible(path))]` into `#[cfg_accessible(path)]`.
This implementation is also incomplete in the sense that it never returns "false" from `cfg_accessible(path)`, it requires some tweaks to resolve, which is not quite ready to answer queries like this during early resolution.
However, the most important part of this PR is not `cfg_accessible` itself, but expansion infrastructure for retrying expansions.
Before this PR we could say "we cannot resolve this macro path, let's try it later", with this PR we can say "we cannot expand this macro, let's try it later" as well.
This is a pre-requisite for
- turning `#[derive(...)]` into a regular attribute macro,
- properly supporting eager expansion for macros that cannot yet be resolved like
```
fn main() {
println!(not_available_yet!());
}
macro_rules! make_available {
() => { #[macro_export] macro_rules! not_available_yet { () => { "Hello world!" } }}
}
make_available!();
```
