Rollup of 10 pull requests #88143
Merged
Rollup of 10 pull requests #88143
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
…doc, r=camelid Fix anchors display in rustdoc Fixes rust-lang#87611 (it simplifies the positioning and fix the background).    r? `@camelid`
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:    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
|
@bors: r+ p=10 rollup=never |
|
📌 Commit 9bbb57c has been approved by |
bors
added
the
S-waiting-on-bors
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
Just want to confirm it's not flaky: @bors retry |
|
⌛ Testing commit 9bbb57c with merge 349ba428d6c9d4c501af72078d99122238be40cd... |
|
💥 Test timed out |
bors
added
S-waiting-on-review
|
@bors retry |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Successful merges:
RawFdfromu32toc_int(i32). #88012 (Change WASI'sRawFdfromu32toc_int(i32).)BuildHasherobject safe #88031 (MakeBuildHasherobject safe)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup