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 #88143

Merged
merged 25 commits into from
Aug 19, 2021
Merged

Conversation

GuillaumeGomez
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

sunfishcode and others added 25 commits August 13, 2021 09:10
WASI previously used `u32` as its `RawFd` type, since its "file descriptors"
are unsigned table indices, and there's no fundamental reason why WASI can't
have more than 2^31 handles.

However, this creates myriad little incompability problems with code
that also supports Unix platforms, where `RawFd` is `c_int`. While WASI
isn't a Unix, it often shares code with Unix, and this difference made
such shared code inconvenient. rust-lang#87329 is the most recent example of such
code.

So, switch WASI to use `c_int`, which is `i32`. This will mean that code
intending to support WASI should ideally avoid assuming that negative file
descriptors are invalid, even though POSIX itself says that file descriptors
are never negative.

This is a breaking change, but `RawFd` is considerd an experimental
feature in [the documentation].

[the documentation]: https://doc.rust-lang.org/stable/std/os/wasi/io/type.RawFd.html
Use more accurate spans when proposing adding lifetime to item
…-c-int, r=alexcrichton

Change WASI's `RawFd` from `u32` to `c_int` (`i32`).

WASI previously used `u32` as its `RawFd` type, since its "file descriptors"
are unsigned table indices, and there's no fundamental reason why WASI can't
have more than 2^31 handles.

However, this creates myriad little incompability problems with code
that also supports Unix platforms, where `RawFd` is `c_int`. While WASI
isn't a Unix, it often shares code with Unix, and this difference made
such shared code inconvenient. rust-lang#87329 is the most recent example of such
code.

So, switch WASI to use `c_int`, which is `i32`. This will mean that code
intending to support WASI should ideally avoid assuming that negative file
descriptors are invalid, even though POSIX itself says that file descriptors
are never negative.

This is a breaking change, but `RawFd` is considerd an experimental
feature in [the documentation].

[the documentation]: https://doc.rust-lang.org/stable/std/os/wasi/io/type.RawFd.html

r? `@alexcrichton`
…e, r=m-ou-se

Make `BuildHasher` object safe

Resolves rust-lang#87991
Fix dead code warning when inline const is used in pattern

Fixes rust-lang#78171
…, r=dns2utf8

Take into account jobs number for rustdoc GUI tests

Fixes rust-lang#88054.

r? `@Mark-Simulacrum`
Fix environment variable getter docs

`@RalfJung` pointed out a number of errors and suboptimal choices I made in my documentation for rust-lang#86183. This PR should (hopefully) fix the problems they've identified.
…p-to-def, r=jhpratt

Add background-color on clickable definitions in source code

Someone suggested to add a decoration on clickable elements in the source code pages:

![Screenshot from 2021-08-17 14-49-39](https://user-images.githubusercontent.com/3050060/129728911-def74f9e-50e2-40d2-b512-e23f1b3d0409.png)
![Screenshot from 2021-08-17 14-49-47](https://user-images.githubusercontent.com/3050060/129728925-14aec500-82ff-4336-955a-4173c769deeb.png)
![Screenshot from 2021-08-17 14-49-52](https://user-images.githubusercontent.com/3050060/129728927-a8a89d7a-e837-4ff5-b094-35be23629d14.png)

The idea is to not disturb the reading while telling the reader "you can click on this one", which is why it's not a text decoration.

What do you think `@rust-lang/rustdoc` ?

r? `@Nemo157`
…s, r=ecstatic-morse

Fix dataflow graphviz bug, make dataflow graphviz modules public

I'm working on a rustc plugin that uses the dataflow framework for MIR analysis. I've found the graphviz utilities extremely helpful for debugging. However, I had to fork the compiler to expose them since they're currently private. I would appreciate if they could be made public so I can build against a nightly instead of a custom fork. Specifically, this PR:

* Makes public the `rustc_mir::dataflow::framework::graphviz` module.
* Makes public the `rustc_mir::util::pretty::write_mir_fn` function.

Here's a concrete example of how I'm using the graphviz module: https://github.com/willcrichton/flowistry/blob/97b843b8b06b4004fbb79b5fcfca3e33c7143bc0/src/slicing/mod.rs#L186-L203

Additionally, this PR fixes a small bug in the diff code that incorrectly shows the updated object as the old object.

r? `@ecstatic-morse`
…i-obk

Move private_unused.rs test to impl-trait

This test was added to fix this issue rust-lang#55124 which is about impl traits but not related with type alias impl traits.

r? `@oli-obk`

`@bors` rollup=always
@rustbot rustbot added the rollup A PR which is a rollup label Aug 18, 2021
@GuillaumeGomez
Copy link
Member Author

@bors: r+ p=10 rollup=never

@bors
Copy link
Contributor

bors commented Aug 18, 2021

📌 Commit 9bbb57c has been approved by GuillaumeGomez

@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 Aug 18, 2021
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
    Finished dev [unoptimized + debuginfo] target(s) in 0.85s
 Documenting settings v0.1.0 (/checkout/src/test/rustdoc-gui/src/settings)
    Finished dev [unoptimized + debuginfo] target(s) in 0.85s
Running 39 rustdoc-gui tests...
(node:17346) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 17 exit listeners added to [process]. Use emitter.setMaxListeners() to increase limit
(Use `node --trace-warnings ...` to show where the warning was created)
(node:17346) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 17 SIGINT listeners added to [process]. Use emitter.setMaxListeners() to increase limit
(node:17346) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 17 SIGTERM listeners added to [process]. Use emitter.setMaxListeners() to increase limit
(node:17346) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 17 SIGHUP listeners added to [process]. Use emitter.setMaxListeners() to increase limit
.......... (20/39)
.......... (30/39)
.........  (39/39)



code-sidebar-toggle... FAILED
[ERROR] (line 3) Error: No node found for selector: #sidebar-toggle: for command `click: "#sidebar-toggle"`



command did not execute successfully: "/node-v14.4.0-linux-x64/bin/node" "/checkout/src/tools/rustdoc-gui/tester.js" "--jobs" "16" "--doc-folder" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/rustdoc-gui/doc" "--tests-folder" "/checkout/src/test/rustdoc-gui"


Build completed unsuccessfully in 0:00:12

@GuillaumeGomez
Copy link
Member Author

Just want to confirm it's not flaky:

@bors retry

@bors
Copy link
Contributor

bors commented Aug 18, 2021

⌛ Testing commit 9bbb57c with merge 349ba428d6c9d4c501af72078d99122238be40cd...

@bors
Copy link
Contributor

bors commented Aug 18, 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 Aug 18, 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

@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 Aug 19, 2021
@bors
Copy link
Contributor

bors commented Aug 19, 2021

⌛ Testing commit 9bbb57c with merge ad1eaff...

@bors
Copy link
Contributor

bors commented Aug 19, 2021

☀️ Test successful - checks-actions
Approved by: GuillaumeGomez
Pushing ad1eaff to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 19, 2021
@bors bors merged commit ad1eaff into rust-lang:master Aug 19, 2021
@rustbot rustbot added this to the 1.56.0 milestone Aug 19, 2021
@bors bors mentioned this pull request Aug 19, 2021
@GuillaumeGomez GuillaumeGomez deleted the rollup-sgh318f branch August 19, 2021 08:04
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.