-
Notifications
You must be signed in to change notification settings - Fork 641
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
chore: reduce dependency to pin-utils #2929
base: master
Are you sure you want to change the base?
Conversation
6bec98d
to
9c206fe
Compare
Signed-off-by: tison <wander4096@gmail.com>
9c206fe
to
6d7ea3e
Compare
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.
Thanks for the PR!
futures-util/src/future/future/mod.rs
(which is a module for Future
trait related things) is not the proper place to put this macro, so perhaps it is better to create futures-util/src/macros.rs
and put it there.
// ever again. | ||
#[allow(unused_mut)] | ||
let mut $x = unsafe { | ||
::core::pin::Pin::new_unchecked(&mut $x) |
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.
This should refer $crate::__private::Pin
instead of ::core::pin::Pin
, as pin-utils does.
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.
Any rationale here?
I'm afraid that, as futures_util::__private
is guarded by async-await
flag, it would create an extra flag gate to use this name.
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.
Any rationale here?
See rust-lang/pin-utils#26 (comment).
I'm afraid that, as
futures_util::__private
is guarded byasync-await
flag, it would create an extra flag gate to use this name.
There is no problem with removing the cfg from __private
module.
That cfg just indicates who the current user is, nothing special.
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.
OK. Let me use $crate::__private
and remove the cfg.
Maybe tomorrow to trigger CI with the new toolchain that fixes the current CI failure.
@taiki-e Thanks for your review! Comments addressed. ... except the one about |
Signed-off-by: tison <wander4096@gmail.com>
c5f4c95
to
3629b06
Compare
Doesn't seem related .. Unsure what happen. |
This is rust-lang/rust#138779. |
Signed-off-by: tison <wander4096@gmail.com>
This refers to #2924.
cc @taiki-e as for "it is reasonable to remove it in v0.4", IIUC I can open a follow-up PR to remove this macro and update the corresponding related usage, only we don't mark that PR as 0.3-backport?
BTW, if there is anything I can help in backporting, please let me know. In my experience, it means opening a PR against branch
0.3
and do the same change.