Enforce Sendability in EventLoopFuture
and EventLoopPromise
methods
#2501
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.
Motivation
With #2496 we fixed a Sendability checking hole by removing the unconditional conformance of
EventLoopFuture/Promise
toSendable
. This was the correct thing to do; however, it has the fallout that a couple of methods are now rightly complaining that their values are send across isolation domains.Modification
This PR requires values on some
ELF/P
methods to beSendable
when we might potentially transfer the values across isolation domains/ELs. We have to be overly aggressive here because we do not know that someELF
method are staying on the same EL. For exampleflatMap
gets a newELF
from the closure provided to it. If theELF
is on the same EL we do not need to hop; however, we can not guarantee this right now from a type level so we have to stay on the safe side and actually require theNewValue
to beSendable
.Result
This PR makes us more correct from a Sendability perspective but produces warnings for some safe patterns that are currently in use.