Skip to content
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

Merged
merged 29 commits into from
Jan 23, 2023
Merged

Conversation

thomaseizinger
Copy link
Contributor

@thomaseizinger thomaseizinger commented Jan 17, 2023

Description

The trick with this one is to use futures::Either everywhere where we may wrap something that implements any of the futures traits. This includes the output of EitherFuture itself. We also need to implement StreamMuxer on future::Either because StreamMuxers may be the the Output of InboundUpgrade.

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

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • A changelog entry has been made in the appropriate crates

@thomaseizinger thomaseizinger mentioned this pull request Jan 17, 2023
7 tasks
Base automatically changed from 2650-remove-either-future2 to master January 18, 2023 10:17
Comment on lines -116 to -206
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!(),
}
}
}
Copy link
Contributor Author

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.

@thomaseizinger thomaseizinger marked this pull request as ready for review January 18, 2023 13:13
@thomaseizinger
Copy link
Contributor Author

This is ready for review @mxinden @jxs.

Copy link
Member

@jxs jxs left a 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>(
Copy link
Member

@jxs jxs Jan 20, 2023

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?

Copy link
Contributor Author

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

Copy link
Member

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!

Copy link
Contributor Author

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?

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 ☺️

Copy link
Member

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 ?

Copy link
Contributor Author

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 ?

Do you mean like line 93? 🙈

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah! right LOL 😂

@thomaseizinger
Copy link
Contributor Author

LGTM Thanks Thomas. The unsafe code seems fine, but if possible I'd rather have it upstream.

Yeah me too. It will merge eventually and it is a private function so I don't think it is blocking :)

@thomaseizinger
Copy link
Contributor Author

Merging here to move forward with #3254.

@thomaseizinger
Copy link
Contributor Author

@Mergifyio requeue

@mergify
Copy link

mergify bot commented Jan 23, 2023

requeue

✅ The queue state of this pull request has been cleaned. It can be re-embarked automatically

@thomaseizinger
Copy link
Contributor Author

@Mergifyio queue

@mergify
Copy link

mergify bot commented Jan 23, 2023

queue

✅ The pull request has been merged automatically

The pull request has been merged automatically at 4b41f5a

@mergify mergify bot merged commit 4b41f5a into master Jan 23, 2023
@mergify mergify bot deleted the 2650-remove-either-output branch January 23, 2023 12:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants