-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Make custom trait object for Future
generic
#51944
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
This comment has been minimized.
This comment has been minimized.
I get the following warnings for the
Can't we simply remove that impl? |
@nikomatsakis Can you help? I'm not sure what to do. I can neither implement |
Crosslink #46205 |
I've removed the Into impls that I removed#[unstable(feature = "futures_api", issue = "50547")]
impl<T, F: Future<Output = T> + Send + 'static> Into<FutureObj<T>> for PinBox<F> {
fn into(self) -> FutureObj<T> {
FutureObj::new(self)
}
}
#[unstable(feature = "futures_api", issue = "50547")]
impl<T, F: Future<Output = T> + Send + 'static> Into<FutureObj<T>> for Box<F> {
fn into(self) -> FutureObj<T> {
FutureObj::new(PinBox::from(self))
}
}
#[unstable(feature = "futures_api", issue = "50547")]
impl<T, F: Future<Output = T> + 'static> Into<LocalFutureObj<T>> for PinBox<F> {
fn into(self) -> LocalFutureObj<T> {
LocalFutureObj::new(self)
}
}
#[unstable(feature = "futures_api", issue = "50547")]
impl<T, F: Future<Output = T> + 'static> Into<LocalFutureObj<T>> for Box<F> {
fn into(self) -> LocalFutureObj<T> {
LocalFutureObj::new(PinBox::from(self))
}
} |
This comment has been minimized.
This comment has been minimized.
82a498c
to
8343be4
Compare
|
I just tried to use it to create async trait methods (including capturing &self with the generic lifetime), it seems to work great. |
This comment has been minimized.
This comment has been minimized.
64372ed
to
1cf9cfb
Compare
I've added an impl for @ngg Thats' great to hear! |
Isn't it unsound for PinMut to implement UnsafeFutureObj? let pinbox = PinBox::new(/*...*/);
let obj1 = FutureObj::new(pinbox.as_pin_mut());
let obj2 = FutureObj::new(pinbox);
drop(obj2); // this will drop the future
executor.spawn(obj1); // I think it's a use-after-free Or does the life-time transfer from PinMut -> UnsafeFutureObj somehow solve this? |
Actually it seems to work properly, it may be sound. |
559f304
to
a954f3b
Compare
|
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
For example |
6ba2a8a
to
8123dec
Compare
@ngg You're right.
|
@ngg Thanks BTW for all your testing :) |
☔ The latest upstream changes (presumably #51969) made this pull request unmergeable. Please resolve the merge conflicts. |
@mikeyhew What's the timeline on object-safe arbitrary-self-types? I'd really like to avoid these custom objects if we don't need them, but perhaps it's a necessary stopgap? That said, |
@MajorBreakfast Thanks as always for this PR!
Yeah, this is great! It's analogous to |
r=me with |
@cramertj they will probably be in nightly within the next month, but not sure when they will be stabilized |
@mikeyhew Cool! Thanks again for working on that. @MajorBreakfast I think with that timeline it's still best for us to push forward with this approach and then we can adjust as necessary-- we need both unsized rvalues and object-safe arbitrary self types before we can totally replace these faked-out trait objects. |
|
Great! @bors r+ p=1 (p=1 because I'd like to get breaking changes to the |
📌 Commit e666c2b has been approved by |
💡 This pull request was already approved, no need to approve it again.
|
📌 Commit e666c2b has been approved by |
@cramertj Are you sure that |
@ngg I don't think it is accurate to say that the "struct does own |
It will not drop |
@ngg |
@cramertj I'm not so sure... I think @ngg is right and we're violating this. I don't think that mentioning the type in the function pointer is enough. Here's what |
Make custom trait object for `Future` generic - `TaskObj` -> `FutureObj<'static, ()>` - The `impl From<...> for FutureObj<'a, T>` impls are impossible because of the type parameter `T`. The impl has to live in libstd, but `FutureObj<'a, T>` is from libcore. Therefore `Into<FutureObj<'a, T>>` was implemented instead. Edit: This didn‘t compile without warnings. I am now using non-generic Form impls. See rust-lang/futures-rs#1058 r? @cramertj Edit: Added lifetime
Yeah that's what I meant but it wouldn't matter to add |
@ngg Yeah, if you could spell |
☀️ Test successful - status-appveyor, status-travis |
TaskObj
->FutureObj<'static, ()>
impl From<...> for FutureObj<'a, T>
impls are impossible because of the type parameterT
. The impl has to live in libstd, butFutureObj<'a, T>
is from libcore. ThereforeInto<FutureObj<'a, T>>
was implemented instead. Edit: This didn‘t compile without warnings. I am now using non-generic Form impls.See rust-lang/futures-rs#1058
r? @cramertj
Edit: Added lifetime