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 9 pull requests #82538

Closed
wants to merge 28 commits into from

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

0yoyoyo and others added 28 commits February 21, 2021 18:29
Turn inlining threshold into optional values to make it possible to
configure different defaults depending on the current mir-opt-level.
WASI's `filestat` type includes a size field, so expose it in
`MetadataExt` via a `size()` function, similar to the corresponding Unix
function.
This adds API documentation support for `std::os::wasi` modeled after
how `std::os::unix` works, so that WASI can be documented [here] along
with the other platforms.

[here]: https://doc.rust-lang.org/stable/std/os/index.html

Two changes of particular interest:

 - This changes the `AsRawFd` for `io::Stdin` for WASI to return
   `libc::STDIN_FILENO` instead of `sys::stdio::Stdin.as_raw_fd()` (and
   similar for `Stdout` and `Stderr`), which matches how the `unix`
   version works. `STDIN_FILENO` etc. may not always be explicitly
   reserved at the WASI level, but as long as we have Rust's `std` and
   `libc`, I think it's reasonable to guarantee that we'll always use
   `libc::STDIN_FILENO` for stdin.

 - This duplicates the `osstr2str` utility function, rather than
   trying to share it across all the configurations that need it.
WASI's `RawFd` is a `u32`, while `libc` uses `c_int`.
This ensures that these names resolve to the right place even when
building the WASI support on other platforms for generating the
documentation.
…oli-obk

Detect match statement intended to be tail expression

CC rust-lang#24157
…tebank

Reword labels on E0308 involving async fn return type

Fix for rust-lang#80658.

When someone writes code like this:

```rust
fn foo() -> u8 {
    async fn async_fn() -> () {}

    async_fn()
}
```

And they try to compile it, they will see an error that looks like this:

```bash
error[E0308]: mismatched types
 --> test.rs:4:5
  |
1 | fn foo() -> u8 {
  |             -- expected `u8` because of return type
2 |     async fn async_fn() -> () {}
  |                            -- checked the `Output` of this `async fn`, found opaque type
3 |
4 |     async_fn()
  |     ^^^^^^^^^^ expected `u8`, found opaque type
  |
  = note: while checking the return type of this `async fn`
  = note:     expected type `u8`
          found opaque type `impl Future`
```
…onymous-lifetime, r=estebank

Improve anonymous lifetime note to indicate the target span

Improvement for  rust-lang#81650
Cc rust-lang#81995

Message after this improvement:
(Improve note in the middle)

```
error[E0311]: the parameter type `T` may not live long enough
  --> src/main.rs:25:11
   |
24 | fn play_with<T: Animal + Send>(scope: &Scope, animal: T) {
   |              -- help: consider adding an explicit lifetime bound...: `T: 'a +`
25 |     scope.spawn(move |_| {
   |           ^^^^^
   |
note: the parameter type `T` must be valid for the anonymous lifetime defined on the function body at 24:40...
  --> src/main.rs:24:40
   |
24 | fn play_with<T: Animal + Send>(scope: &Scope, animal: T) {
   |                                        ^^^^^
note: ...so that the type `[closure@src/main.rs:25:17: 27:6]` will meet its required lifetime bounds
  --> src/main.rs:25:11
   |
25 |     scope.spawn(move |_| {
   |           ^^^^^
```

r? ````@estebank````
Add option to enable MIR inlining independently of mir-opt-level

Add `-Zinline-mir` option that enables MIR inlining independently of the
current MIR opt level. The primary use-case is enabling MIR inlining on the
default MIR opt level.

Turn inlining thresholds into optional values to make it possible to configure
different defaults depending on the current mir-opt-level (although thresholds
are yet to be used in such a manner).
…mps, r=petrochenkov

Test hexagon-enum only when llvm target is present

See rust-lang#82379 (comment)

r? ````@petrochenkov````

````@bors```` rollup
expand: Preserve order of inert attributes during expansion

Fixes rust-lang#67839
Fixes rust-lang#81871
r? ```@Aaron1011```
Enable API documentation for `std::os::wasi`.

This adds API documentation support for `std::os::wasi` modeled after
how `std::os::unix` works, so that WASI can be documented [here] along
with the other platforms.

[here]: https://doc.rust-lang.org/stable/std/os/index.html

Two changes of particular interest:

 - This changes the `AsRawFd` for `io::Stdin` for WASI to return
   `libc::STDIN_FILENO` instead of `sys::stdio::Stdin.as_raw_fd()` (and
   similar for `Stdout` and `Stderr`), which matches how the `unix`
   version works. `STDIN_FILENO` etc. may not always be explicitly
   reserved at the WASI level, but as long as we have Rust's `std` and
   `libc`, I think it's reasonable to guarantee that we'll always use
   `libc::STDIN_FILENO` for stdin.

 - This duplicates the `osstr2str` utility function, rather than
   trying to share it across all the configurations that need it.

r? `@alexcrichton`
…lexcrichton

Add a `size()` function to WASI's `MetadataExt`.

WASI's `filestat` type includes a size field, so expose it in
`MetadataExt` via a `size()` function, similar to the corresponding Unix
function.

r? ````@alexcrichton````
@rustbot rustbot added the rollup A PR which is a rollup label Feb 26, 2021
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Feb 26, 2021

📌 Commit 171ee33 has been approved by Dylan-DPC

@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 Feb 26, 2021
@bors
Copy link
Contributor

bors commented Feb 26, 2021

⌛ Testing commit 171ee33 with merge 11d3d1d2add64c2fe528f78d60f0fe5f0ba6f98d...

@bors
Copy link
Contributor

bors commented Feb 26, 2021

💥 Test timed out

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

@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 Feb 26, 2021
@bors
Copy link
Contributor

bors commented Feb 26, 2021

⌛ Testing commit 171ee33 with merge 5dd58b60acb711b3e1bc1a0fca70ef6362e28590...

@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)

@bors
Copy link
Contributor

bors commented Feb 26, 2021

💥 Test timed out

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 26, 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)

@bors
Copy link
Contributor

bors commented Feb 26, 2021

☔ The latest upstream changes (presumably #82552) made this pull request unmergeable. Please resolve the merge conflicts.

@Dylan-DPC-zz Dylan-DPC-zz deleted the rollup-004517a branch February 27, 2021 00:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.