Rollup of 11 pull requests #87567
Closed
Rollup of 11 pull requests #87567
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The `Unpin` bound was originally added in rust-lang#56939 following the recommendation of @withoutboats in rust-lang#55766 (comment) That comment does not give explicit justification for why the bound should be added. The relevant context was: > [ ] Remove `impl<P> Unpin for Pin<P>` > > This impl is not justified by our standard justification for unpin > impls: there is no pointer direction between `Pin<P>` and `P`. Its > usefulness is covered by the impls for pointers themselves. > > This futures impl (link to the impl changed in this PR) will need to > change to add a `P: Unpin` bound. The decision to remove the unconditional impl of `Unpin for Pin` is sound (these days there is just an auto-impl for when `P: Unpin`). But, I think the decision to also add the `Unpin` bound for `impl Future` may have been unnecessary. Or if that's not the case, I'd be very interested to have the argument for why written down somewhere. The bound _appears_ to not be needed, since the presence of a `Pin<P>` should indicate that it's safe to project to `Pin<&mut P::Target>` just like for `Pin::as_mut`.
Co-authored-by: Ralf Jung <post@ralfj.de>
I didn't notice the submodule, which means I failed to re-export this to make it actually-public. Reported-by: Andrew Gallant <jamslam@gmail.com> Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
I looked in stdlib and as @BurntSushi thought, `raw` is generally used for raw pointers, or other hazardous kinds of thing. stdlib does not have `into_parts` apart from the one I added to `IntoInnerError`. I did an ad-hoc search of the rustdocs for my current game project Otter, which includes quite a large number of dependencies. `into_parts` seems heavily used for things quite like this. So change this name. Suggested-by: Andrew Gallant <jamslam@gmail.com> Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
As requested rust-lang#85901 (review) Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
…uple for tuple structs in enums
Add `mkdir` to `create_dir`, `rmdir` to `remove_dir`.
…=m-ou-se Stabilize core::task::ready! _Tracking issue: https://github.com/rust-lang/rust/issues/70922_ This PR stabilizes the `task::ready!` macro. Similar to rust-lang#80886, this PR was waiting on rust-lang#74355 to be fixed. The `task::ready!` API has existed in the futures ecosystem for several years, and was added on nightly last year in rust-lang#70817. The motivation for this macro is the same as it was back then: virtually every single manual future implementation makes use of this; so much so that it's one of the few things included in the [futures-core](https://docs.rs/futures-core/0.3.12/futures_core) library. r? `@tmandry` cc/ `@rust-lang/wg-async-foundations` `@rust-lang/libs` ## Example ```rust use core::task::{Context, Poll}; use core::future::Future; use core::pin::Pin; async fn get_num() -> usize { 42 } pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut f = get_num(); let f = unsafe { Pin::new_unchecked(&mut f) }; let num = ready!(f.poll(cx)); // ... use num Poll::Ready(()) } ```
… r=m-ou-se Remove P: Unpin bound on impl Future for Pin We can safely produce a `Pin<&mut P::Target>` without moving out of the `Pin` by using `Pin::as_mut` directly. The `Unpin` bound was originally added in rust-lang#56939 following the recommendation of `@withoutboats` in rust-lang#55766 (comment) That comment does not give explicit justification for why the bound should be added. The relevant context was: > [ ] Remove `impl<P> Unpin for Pin<P>` > > This impl is not justified by our standard justification for unpin impls: there is no pointer direction between `Pin<P>` and `P`. Its usefulness is covered by the impls for pointers themselves. > > This futures impl (link to the impl changed in this PR) will need to change to add a `P: Unpin` bound. The decision to remove the unconditional impl of `Unpin for Pin` is sound (these days there is just an auto-impl for when `P: Unpin`). But, I think the decision to also add the `Unpin` bound for `impl Future` may have been unnecessary. Or if that's not the case, I'd be very interested to have the argument for why written down somewhere. The bound _appears_ to not be needed, as demonstrated by the change requiring no unsafe code and by the existence of `Pin::as_mut`.
…iplett Bufwriter disassembly tweaks In rust-lang#80690 `@BurntSushi` observed that `WriterPanicked` was erroneously not exported, and suggested renaming `into_raw_parts` to `into_parts`. (More info in my commit messages.) r? `@BurntSushi`
Add doc aliases to fs.rs Add aliases for create_dir, create_dir_all, remove_dir, remove_dir_all
fix example code for E0617 Closes rust-lang#86908
…oc, r=jyn514 Add support for tuple struct field documentation Fixes rust-lang#42615. This is rust-lang#80320 updated to new codebase and with added tests. Part of rust-lang#83255. cc ``@camelid`` (since you were involved on the original PR). r? ``@jyn514``
…rk-Simulacrum Integrate context into the memorial to Anna This came up after I reviewed rust-lang#87298, but I didn't propose this in time before that PR was merged. If y'all feel this is too much churn on the file, no worries, feel free to close, but I felt this was a more fitting integration of the memorial into the test suite. CC `@boringcactus.`
Add long explanation for E0498 Helps with rust-lang#61137
…oli-obk Don't run MIR unsafeck at all when using `-Zthir-unsafeck` I don't know how I missed this :D r? `@oli-obk`
…r=Mark-Simulacrum Add `CI_ONLY_WHEN_CHANNEL` and run `x86_64-gnu-stable` only on nightly Backporting a commit made on rust-lang#87508. cc `@Mark-Simulacrum`
Use backticks when referring to `core::future::Ready` in panic message
|
@bors r+ p=11 rollup=never |
|
📌 Commit ecaf978 has been approved by |
bors
added
the
S-waiting-on-bors
|
The job Click to see the possible cause of the failure (guessed by this bot) |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
-Zthir-unsafeck#87527 (Don't run MIR unsafeck at all when using-Zthir-unsafeck)CI_ONLY_WHEN_CHANNELand runx86_64-gnu-stableonly on nightly #87550 (AddCI_ONLY_WHEN_CHANNELand runx86_64-gnu-stableonly on nightly)core::future::Readyin panic message #87565 (Use backticks when referring tocore::future::Readyin panic message)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup