-
Notifications
You must be signed in to change notification settings - Fork 957
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
refactor(core)!: remove EitherOutput
#3341
Conversation
impl<LOP, ROP, LOOI, ROOI> | ||
FullyNegotiatedOutbound<Either<SendWrapper<LOP>, SendWrapper<ROP>>, Either<LOOI, ROOI>> | ||
where | ||
LOP: OutboundUpgradeSend, | ||
ROP: OutboundUpgradeSend, | ||
{ | ||
fn transpose( | ||
self, | ||
) -> Either<FullyNegotiatedOutbound<LOP, LOOI>, FullyNegotiatedOutbound<ROP, ROOI>> { | ||
match self { | ||
FullyNegotiatedOutbound { | ||
protocol: EitherOutput::First(protocol), | ||
info: Either::Left(info), | ||
} => Either::Left(FullyNegotiatedOutbound { protocol, info }), | ||
FullyNegotiatedOutbound { | ||
protocol: EitherOutput::Second(protocol), | ||
info: Either::Right(info), | ||
} => Either::Right(FullyNegotiatedOutbound { protocol, info }), | ||
_ => unreachable!(), | ||
} | ||
} | ||
} | ||
|
||
impl<LOP, ROP, LOOI, ROOI> | ||
DialUpgradeError<Either<LOOI, ROOI>, Either<SendWrapper<LOP>, SendWrapper<ROP>>> | ||
where | ||
LOP: OutboundUpgradeSend, | ||
ROP: OutboundUpgradeSend, | ||
{ | ||
fn transpose(self) -> Either<DialUpgradeError<LOOI, LOP>, DialUpgradeError<ROOI, ROP>> { | ||
match self { | ||
DialUpgradeError { | ||
error: ConnectionHandlerUpgrErr::Upgrade(UpgradeError::Apply(Either::Left(error))), | ||
info: Either::Left(info), | ||
} => Either::Left(DialUpgradeError { | ||
error: ConnectionHandlerUpgrErr::Upgrade(UpgradeError::Apply(error)), | ||
info, | ||
}), | ||
DialUpgradeError { | ||
error: ConnectionHandlerUpgrErr::Upgrade(UpgradeError::Apply(Either::Right(error))), | ||
info: Either::Right(info), | ||
} => Either::Right(DialUpgradeError { | ||
error: ConnectionHandlerUpgrErr::Upgrade(UpgradeError::Apply(error)), | ||
info, | ||
}), | ||
DialUpgradeError { | ||
error: ConnectionHandlerUpgrErr::Upgrade(UpgradeError::Select(error)), | ||
info: Either::Left(info), | ||
} => Either::Left(DialUpgradeError { | ||
error: ConnectionHandlerUpgrErr::Upgrade(UpgradeError::Select(error)), | ||
info, | ||
}), | ||
DialUpgradeError { | ||
error: ConnectionHandlerUpgrErr::Upgrade(UpgradeError::Select(error)), | ||
info: Either::Right(info), | ||
} => Either::Right(DialUpgradeError { | ||
error: ConnectionHandlerUpgrErr::Upgrade(UpgradeError::Select(error)), | ||
info, | ||
}), | ||
DialUpgradeError { | ||
error: ConnectionHandlerUpgrErr::Timer, | ||
info: Either::Left(info), | ||
} => Either::Left(DialUpgradeError { | ||
error: ConnectionHandlerUpgrErr::Timer, | ||
info, | ||
}), | ||
DialUpgradeError { | ||
error: ConnectionHandlerUpgrErr::Timer, | ||
info: Either::Right(info), | ||
} => Either::Right(DialUpgradeError { | ||
error: ConnectionHandlerUpgrErr::Timer, | ||
info, | ||
}), | ||
DialUpgradeError { | ||
error: ConnectionHandlerUpgrErr::Timeout, | ||
info: Either::Left(info), | ||
} => Either::Left(DialUpgradeError { | ||
error: ConnectionHandlerUpgrErr::Timeout, | ||
info, | ||
}), | ||
DialUpgradeError { | ||
error: ConnectionHandlerUpgrErr::Timeout, | ||
info: Either::Right(info), | ||
} => Either::Right(DialUpgradeError { | ||
error: ConnectionHandlerUpgrErr::Timeout, | ||
info, | ||
}), | ||
_ => unreachable!(), | ||
} | ||
} | ||
} |
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.
These can now go away because we unified the either types and there is already an implementation for it.
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.
LGTM Thanks Thomas. The unsafe code seems fine, but if possible I'd rather have it upstream.
/// pinned projections of the inner variants. | ||
/// | ||
/// Local function until <https://github.com/rust-lang/futures-rs/pull/2691> is merged. | ||
fn as_pin_mut<A, B>( |
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.
Should we ask for project to be public? As it seems the same purpose and would allow us to not have unsafe code here.
update:
sorry only now saw rayon-rs/either#76, can't we use as_pin_mut
from either::Either
?
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.
Should we ask for project to be public? As it seems the same purpose and would allow us to not have unsafe code here.
See rust-lang/futures-rs#2629 (comment) :)
This is the future::Either
type, we can't use either::Either
here because it doesn't implement AsyncRead
etc
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.
yeah I saw after, thanks Thomas :)
It it would be nice for either::Either
to implement the futures
traits as you asked on rayon-rs/either#79. But it seems you also submitted rust-lang/futures-rs#2691 which will allow us to remove the unsafe
code right? Ideally what would be really nice was for a single Either
type 😀 which will be possible when rust-lang/futures-rs#2691 is merged right? Nonetheless thanks for your work simplifying this Thomas!
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.
yeah I saw after, thanks Thomas :)
It it would be nice foreither::Either
to implement thefutures
traits as you asked on rayon-rs/either#79. But it seems you also submitted rust-lang/futures-rs#2691 which will allow us to remove theunsafe
code right?
Correct!
Ideally what would be really nice was for a single
Either
type 😀 which will be possible when rust-lang/futures-rs#2691 is merged right?
Not quite unfortunately, we also use Either
in places where it needs to implement std::error::Error
for example and futures::Either
doesn't AFAIK. I agree that it would be nice but at least after these patches, we don't have a problem with there being two different Either
types.
Nonetheless thanks for your work simplifying this Thomas!
You are welcome
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.
wdyt of then leaving a TODO
on the unsafe code to be removed when a futures
gets released with rust-lang/futures-rs#2691 ?
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.
wdyt of then leaving a
TODO
on the unsafe code to be removed when afutures
gets released with rust-lang/futures-rs#2691 ?
Do you mean like line 93? 🙈
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.
ah! right LOL 😂
Yeah me too. It will merge eventually and it is a private function so I don't think it is blocking :) |
Merging here to move forward with #3254. |
@Mergifyio requeue |
✅ The queue state of this pull request has been cleaned. It can be re-embarked automatically |
@Mergifyio queue |
✅ The pull request has been merged automaticallyThe pull request has been merged automatically at 4b41f5a |
Description
The trick with this one is to use
futures::Either
everywhere where we may wrap something that implements any of thefutures
traits. This includes the output ofEitherFuture
itself. We also need to implementStreamMuxer
onfuture::Either
becauseStreamMuxer
s may be the theOutput
ofInboundUpgrade
.Notes
Draft because it doesn't compile yet.This should unblock the compile errors I've been getting while resolving the merge conflicts in #3254.
Links to any relevant issues
Open Questions
Change checklist