-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Let try_collect
take advantage of try_fold
overrides
#94115
Conversation
Took me a second to figure out why you didn't have to edit the @bors r+ |
📌 Commit 2cbba35793b4cee97f0d29b3ace18bdb77d6426c has been approved by |
I have concerns about whether this is valid for the |
Hope you don't mind. @bors r- |
Indeed, this is incompatible with this safety requirement rust/library/core/src/iter/adapters/mod.rs Lines 103 to 108 in b8c56fa
You cannot be sure to have dropped the iterator pipeline (that is, including the source) if it can take a The unsafe traits are used to optimize iterators such as this one to run in place vec.into_iter().map(Foo::something_returning_result).collect::<Result<Vec<_>, _>>() |
Thanks, @the8472! Definitely don't mind an Does anyone have thoughts on the best way for me to move forward, here? Should I make a separate |
Another option is to use |
You could also keep using |
iter::try_process
doesn't need ownership, so take &mut
insteadtry_collect
take advantage of try_fold
overrides
2cbba35
to
ee50c35
Compare
Rather than use specialization, I added a That seems most obviously correct to me, is potentially re-usable, and would be an easy thing to remove if specialization ever removes the suboptimality from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks ok from the safety perspective now. The new adapter doesn't match other adapters in usual optimizations that are applied (inline annotations, TrustedLen
and similar traits).
Some microbenchmarking could help, but that can be done in a separate PR.
Additionally an internal comment pointing from impl Iterator for &mut Iterator
to the adapter could be useful to maintain awareness if someone tries to optimize or use that in the future.
☔ The latest upstream changes (presumably #94787) made this pull request unmergeable. Please resolve the merge conflicts. |
Without this change it's going through `&mut impl Iterator`, which handles `?Sized` and thus currently can't forward generics. Here's the test added, to see that it fails before this PR (once a new enough nightly is out): https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=462f2896f2fed2c238ee63ca1a7e7c56
ee50c35
to
7ef74bc
Compare
📌 Commit 7ef74bc has been approved by |
Let `try_collect` take advantage of `try_fold` overrides No public API changes. With this change, `try_collect` (rust-lang#94047) is no longer going through the `impl Iterator for &mut impl Iterator`, and thus will be able to use `try_fold` overrides instead of being forced through `next` for every element. Here's the test added, to see that it fails before this PR (once a new enough nightly is out): https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=462f2896f2fed2c238ee63ca1a7e7c56 This might as well go to the same person as my last `try_process` PR (rust-lang#93572), so r? `@yaahc`
…askrgr Rollup of 7 pull requests Successful merges: - rust-lang#94115 (Let `try_collect` take advantage of `try_fold` overrides) - rust-lang#94295 (Always evaluate all cfg predicate in all() and any()) - rust-lang#94848 (Compare installed browser-ui-test version to the one used in CI) - rust-lang#94993 (Add test for >65535 hashes in lexing raw string) - rust-lang#95017 (Derive Eq for std::cmp::Ordering, instead of using manual impl.) - rust-lang#95058 (Add use of bool::then in sys/unix/process) - rust-lang#95083 (Document that `Option<extern "abi" fn>` discriminant elision applies for any ABI) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
No public API changes.
With this change,
try_collect
(#94047) is no longer going through theimpl Iterator for &mut impl Iterator
, and thus will be able to usetry_fold
overrides instead of being forced throughnext
for every element.Here's the test added, to see that it fails before this PR (once a new enough nightly is out): https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=462f2896f2fed2c238ee63ca1a7e7c56
This might as well go to the same person as my last
try_process
PR (#93572), sor? @yaahc