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

Rollup of 10 pull requests #86321

Merged
merged 22 commits into from
Jun 15, 2021
Merged

Rollup of 10 pull requests #86321

merged 22 commits into from
Jun 15, 2021

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

scottmcm and others added 22 commits May 23, 2021 13:20
Original senders that are still hanging around could cause
Receiver::recv to not block since this is a potential footgun
for beginners, clarify more on this in the docs for readers to
be aware about it.

Fix minor tidbits in sender recv doc

Co-authored-by: Dylan DPC <dylan.dpc@gmail.com>

Add example for unbounded receive loops in doc

Show the drop(tx) pattern, based on tokio docs
https://tokio-rs.github.io/tokio/doc/tokio/sync/index.html

Fix example code for drop sender recv

Fix wording in sender docs

Co-authored-by: Josh Triplett <josh@joshtriplett.org>
This is a fairly common attribute on methods, but is not something you
need to know when reading the method docs - the purpose of the attribute
is for the compiler to tell you about it if you forget to use a value.

Removing reclaims some valuable space in the summary of methods.
This also adds the error type used, `FromSecsError` and its `impl`s.
`Duration::from_secs_{f32, f64}` now use the results from the
non-panicking functions and unwrap it.
Explain non-dropped sender recv in docs

Original senders that are still hanging around could cause
Receiver::recv to not block since this is a potential footgun
for beginners, clarify more on this in the docs for readers to
be aware about it.

Maybe it would be better to show an example of the pattern where `drop(tx)` is used when it is being cloned multiple times? Although I have seen it in quite a few articles but I am surprised that this part is not very clear with the current words without careful reading.

> If the corresponding Sender has disconnected, or it disconnects while this call is blocking, this call will wake up and return Err to indicate that no more messages can ever be received on this channel. However, since channels are buffered, messages sent before the disconnect will still be properly received.

Some words there may seemed similar if I carefully read and relate it but if I am new, I probably does not know "drop" makes it "disconnected". So I mention the words "drop" and "alive" to make it more relatable to lifetime.
Add functions `Duration::try_from_secs_{f32, f64}`

These functions allow constructing a Duration from a floating point value that could be out of range without panicking.

Tracking issue: rust-lang#83400
…m-basics, r=m-ou-se

Stabilize `ops::ControlFlow` (just the type)

Tracking issue: rust-lang#75744 (which also tracks items *not* closed by this PR).

With the new `?` desugar implemented, [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6).  (At the time of making this PR, godbolt was still on the 2021-05-01 nightly, where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).)  That resolves the only blocker I know of, so I'd like to propose that `ControlFlow` be considered for stabilization.

Its basic existence was part of rust-lang/rfcs#3058, where it got a bunch of positive comments (examples [1](rust-lang/rfcs#3058 (comment)) [2](rust-lang/rfcs#3058 (review)) [3](rust-lang/rfcs#3058 (comment)) [4](rust-lang/rfcs#3058 (comment))).  Its use in the compiler has been well received (rust-lang#78182 (comment)), and there are ecosystem updates interested in using it (rust-itertools/itertools#469 (comment), jonhoo/rust-imap#194).

As this will need an FCP, picking a libs member manually:
r? `@m-ou-se`

## Stabilized APIs

```rust
#[derive(Debug, Clone, Copy, PartialEq)]
pub enum ControlFlow<B, C = ()> {
    /// Exit the operation without running subsequent phases.
    Break(B),
    /// Move on to the next phase of the operation as normal.
    Continue(C),
}
```

As well as using `?` on a `ControlFlow<B, _>` in a function returning `ControlFlow<B, _>`.  (Note, in particular, that there's no `From::from`-conversion on the `Break` value, the way there is for `Err`s.)

## Existing APIs *not* stabilized here

All the associated methods and constants: `break_value`, `is_continue`, `map_break`, [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE), etc.

Some of the existing methods in nightly seem reasonable, some seem like they should be removed, and some need more discussion to decide.  But none of them are *essential*, so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow), they're all omitted from this PR.

They can be considered separately later, as further usage demonstrates which are important.
…=JohnTitor

Refactor windows sockets impl methods

No behavioural changes, but a bit tidier visual flow.
Remove must_use from ALLOWED_ATTRIBUTES

This is a fairly common attribute on methods, but is not something you need to know when reading the method docs - the purpose of the attribute is for the compiler to tell you about it if you forget to use a value.

Removing reclaims some valuable space in the summary of methods, particularly when the attribute has a long string value.

As discussed in rust-lang#84309. Partially addresses rust-lang#81482.

r? ```@Manishearth```
…joshtriplett

Stabilize {std, core}::prelude::rust_*.

This stabilizes the `{core, std}::prelude::{rust_2015, rust_2018, rust_2021}` modules.

The usage of these modules as the prelude in those editions was already stabilized. This just stabilizes the modules themselves, making it possible for a user to explicitly refer to them.

Tracking issue: rust-lang#85684

FCP on the RFC that included this finished here: rust-lang/rfcs#3114 (comment)
Remove trailing triple backticks in `mut_keyword` docs
@rustbot rustbot added the rollup A PR which is a rollup label Jun 15, 2021
@JohnTitor
Copy link
Member Author

@bors r+ p=10 rollup=never

@bors
Copy link
Contributor

bors commented Jun 15, 2021

📌 Commit 74cc63a has been approved by JohnTitor

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jun 15, 2021
@bors
Copy link
Contributor

bors commented Jun 15, 2021

⌛ Testing commit 74cc63a with merge 7231a5e737f75ea553719b2d5aab2658bce27e16...

@bors
Copy link
Contributor

bors commented Jun 15, 2021

💥 Test timed out

@bors bors removed the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jun 15, 2021
@bors bors added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 15, 2021
@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@JohnTitor
Copy link
Member Author

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 15, 2021
@bors
Copy link
Contributor

bors commented Jun 15, 2021

⌛ Testing commit 74cc63a with merge 607d6b0...

@bors
Copy link
Contributor

bors commented Jun 15, 2021

☀️ Test successful - checks-actions
Approved by: JohnTitor
Pushing 607d6b0 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 15, 2021
@bors bors merged commit 607d6b0 into rust-lang:master Jun 15, 2021
@rustbot rustbot added this to the 1.55.0 milestone Jun 15, 2021
@JohnTitor JohnTitor deleted the rollup-q61c8q4 branch June 15, 2021 23:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.