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

0.3: Backports #2389

Merged
merged 13 commits into from
Apr 10, 2021
Merged

0.3: Backports #2389

merged 13 commits into from
Apr 10, 2021

Conversation

taiki-e
Copy link
Member

@taiki-e taiki-e commented Apr 10, 2021

Backports:

stepancheg and others added 13 commits April 10, 2021 14:48
When select all is not yet finished (for example, due to timeout),
underlying futures may need to be extracted to be updated to construct
a fresh select all.
After rust-lang#2216, these redundant imports are unneeded.
This reverts almost all of rust-lang#2101.
This also includes some minor cleanup of imports in tests.
If the test is related to a particular module, use the file name
starting with the module name.
Add `.editorconfig` with sensible defaults.

Many editors understand editorconfig, and the most important one
here is IntelliJ IDEA which does not insert file trailing newline
by default, but does it out of box this provided `.editorconfig`.
Allow calling `UnboundedReceiver::try_next` and `Receiver::try_next`
after `None`: do not panic.

Not-panicking is equally safe, and does not have negative performance
implication.

It is irrelevant for `Stream` implementation to panic or not (because
`Stream` behavior is unspecified after `None`), but panicking in
`try_next` just complicates the interface: returned `Ok(None)` is
reasonable assumption to have.

Consider this use case: drain the queue on drop by performing
app-specific cleanup of queued messages.

The obvious implementation would be:

```
impl Drop for MyReceiverWrapper {
    fn drop(&mut self) {
        while let Ok(Some(m)) self.try_next() {
            cleanup(m);
        }
    }
}
```

Without this change, I cannot even say for sure how this code need
to be implemented to avoid panicking. E. g. is `is_closed` enough
or some additional checks need to be performed?
Similar change applied to `UnboundedReceiver::try_next` a few commits ago.
@taiki-e taiki-e added the futures-0.3 Issue related to the 0.3 versions of futures label Apr 10, 2021
@taiki-e taiki-e merged commit 071a434 into rust-lang:0.3 Apr 10, 2021
@taiki-e taiki-e deleted the 0.3-backports branch April 10, 2021 06:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
futures-0.3 Issue related to the 0.3 versions of futures
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants