-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rollup of 10 pull requests #140877
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
Closed
Closed
Rollup of 10 pull requests #140877
+286
−224
Conversation
This file contains hidden or 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
…est-build-arg` More notably, the value of the new flag does *not* get lexed shell-like and ad hoc.
In rare cases, the test may need access to the underlying `std::process::Command` (e.g. for non-trivial process spawning). Co-authored-by: Jesus Checa Hidalgo <[email protected]>
Where host compiler runtime libs are properly configured, instead of raw `RUSTC`/`RUSTDOC` commands. Co-authored-by: Jesus Checa Hidalgo <[email protected]>
This change is based on some discussion on [lolbinarycat's idea], but with a more "traditional" design. Specifically, this is the closest thing I could find to a consensus across many systems I looked at for inspiration: - In Jira, resizable sidebars have a stack of four dots. - In The GIMP, resizable sidebars have a stack of three dots. - In [old Windows], "panes" are defined to have the same border style as a window, which has a raised appearance. - In [NeXT], a drag point usually had an innie, whether the line in a slider or the circle in a scroller; I can also hide and show the favorites bar in Workspace by dragging on a circular "grip spot" - In [old Mac], drag handles for things usually had a "grip track" of parallel lines. - [OSX] kept that, but the "Source List" part of the Finder still had the circle grip for a time the same way Workspace did [lolbinarycat's idea]: rust-lang#139420 [old Windows]: https://archive.org/details/windowsinterface00micr/page/n9/mode/2up [old Mac]: https://archive.org/details/apple-hig/1996_Human_Interface_Guidelines_for_Mac_OS_8_%28WWDC_Release%29/page/16/mode/2up [NeXT]: https://archive.org/details/apple-hig/1993%20NeXTSTEP%20User%20Interface%20Guidelines%20-%20Release%203/page/145/mode/2up [OSX]: https://dn721903.ca.archive.org/0/items/apple-hig/MacOSX_HIG_2005_09_08.pdf#page=267
…uillaumeGomez rustdoc: add a handle that makes sidebar resizing more obvious This aims to make the resizable sidebars more obvious Preview: <https://notriddle.com/rustdoc-html-demo-12/sidebar-resize-handle/std/index.html>    This change is based on some discussion on [lolbinarycat's idea], but with a more "traditional" design. Specifically, while very few systems use exactly this design, most of them use [a skeumorph](https://ux.stackexchange.com/questions/80463/what-do-the-3-close-horizontal-bars-not-hamburger-menu-represent-and-what-is-t/80591#80591) of a grip texture: - This design is similar to the one used in the Rust Playground, and almost identical to UX StackExchange: <details><img src="https://github.com/user-attachments/assets/39a6bb69-4895-4fd0-87da-b87913bc7309"></details> <details><img src="https://github.com/user-attachments/assets/a41942e1-651b-410b-b855-2aafe8fe54f4"></details> - In Jira, resizable sidebars have a stack of four dots, but only in one row. <details><img src="https://github.com/user-attachments/assets/13047998-02bf-47e6-b796-16f393f870b0"></details> - In The GIMP, resizable sidebars have a stack of three dots. <details><img src="https://github.com/user-attachments/assets/138f5c21-3069-4bbe-b306-0bb9a4bf0318"></details> - In [old Windows], "panes" are defined to have the same border style as a window, which has a raised appearance. To evoke this, the PR adds a lightweight "shadow" border, darker than the sidebar itself <details><img src="https://github.com/user-attachments/assets/301da4b8-6c48-4131-b741-1689af84670a"></details> - In [NeXT], a drag point usually had an innie, whether the line in a slider or the circle in a scroller; I can also hide and show the favorites bar in Workspace by dragging on a circular "grip spot" <details><img src="https://github.com/user-attachments/assets/b13c2d30-a3a8-4672-90fa-58c1fdf19f42"></details> - In [old Mac], drag handles for things usually had a "grip track" of parallel lines. <details><img src="https://github.com/user-attachments/assets/1fbecc67-ffbc-4ed6-a8c5-a9ff085638db"></details> *This design is far closer to old Mac than anything else*, though they've put it in the bottom corner instead of the middle. - [OSX] kept that, but the "Source List" part of the Finder still had the circle grip for a time the same way Workspace did (resulting in an odd mishmash, if you compare the source list sidebar with the other grip tracks embedded in the scrollbars). <details><img src="https://github.com/user-attachments/assets/551b8f9d-2dd8-4291-917f-dc88741a2b97"></details> [lolbinarycat's idea]: rust-lang#139420 [old Windows]: https://archive.org/details/windowsinterface00micr/page/n9/mode/2up [old Mac]: https://archive.org/details/apple-hig/1996_Human_Interface_Guidelines_for_Mac_OS_8_%28WWDC_Release%29/page/16/mode/2up [NeXT]: https://archive.org/details/apple-hig/1993%20NeXTSTEP%20User%20Interface%20Guidelines%20-%20Release%203/page/145/mode/2up [OSX]: https://dn721903.ca.archive.org/0/items/apple-hig/MacOSX_HIG_2005_09_08.pdf#page=267
…ing, r=GuillaumeGomez rustdoc: Replace unstable flag `--doctest-compilation-args` with a simpler one: `--doctest-build-arg` Tracking issue: rust-lang#134172. Context: rust-lang#137096 (comment) Yeets the ad hoc shell-like lexer for 'nested' program arguments. No FCP necessary since the flag is unstable. I've chosen to replace `compilation` with `build` because it's shorter (you now need to pass it multiple times in order to pass many arguments to the doctest compiler, so it matters a bit) and since I prefer it esthetically. **Issue**: Even though we don't process the argument passed to `--doctest-build-arg`, we end up passing it via an argument file (`rustc ``@argfile`)`` which delimits arguments by line break (LF or CRLF, [via](https://doc.rust-lang.org/rustc/command-line-arguments.html#path-load-command-line-flags-from-a-path)) meaning ultimately the arguments still get split which is unfortunate. Still, I think this change is an improvement over the status quo. I'll update the tracking issue if/once this PR merges. I'll also add the (CR)LF issue to 'unresolved question'. r? GuillaumeGomez r? notriddle
…-Simulacrum Update hermit-abi to 0.5.1 This updates hermit-abi to version 0.5.1, bringing the [recent `AF_*`](rust-lang/libc#4344) changes to std.
…Gomez also export metrics from librustdoc Addresses the issue mentioned here: [#t-docs-rs > metrics intitiative @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/356853-t-docs-rs/topic/metrics.20intitiative/near/515714331) The previous implementation only emitted metrics from rustc, but it turns out running `cargo doc` only calls `rustc` for dependencies, and not for the root crate being documented. We are planning to gather a sample dataset from docs.rs ci via `cargo doc` so as things stood this would not emit any metrics for any of the crates themselves that were published. This change adds the same logic from `rustc_driver_impl` to `librustdoc` to also dump metrics at the end of its execution if they are enabled. Note: The hash's generated by librustdoc will likely be completely different from the ones generated by rustc. This is because rustc is actually doing the various passes needed to fully calculate the stable version hash. My understanding of how rustdoc works is that the hashes generated will be working with partial information due to it only doing the work required to generate docs. The hashes will still be unique per crate and will work for the purposes of the metrics proof of concept, it would not be possible to correlate metrics generated by rustdoc with those generated by rustc for the same crate. This is fine for the purposes of the PoC but a future full implementation of metrics may want to address this issue.
…nkov Add regression test for 125877 close: rust-lang#125877 rust-lang#125877 (comment) has been resolved rust-lang#128171
Fix `broken-pipe-no-ice` run-make test for rpath-less builds The `broken-pipe-no-ice` run-make test currently fails on rpath-less builds, because host compiler runtime libs are not configured for raw std command usages. This PR is an alternative approach to rust-lang#140744. However, instead of duplicating `run_make_support::util::set_host_compiler_dylib_path` logic, we instead support "ejecting" the "configured" underlying std `Command` from `bare_rustc()` and `rustdoc()`, where host compiler runtime libs are already set. cc ``@jchecahi`` r? ``@Kobzol``
…er-errors Improved error message for top-level or-patterns I was confused by "top-level or-patterns are not allowed in `let` bindings" error, because it sounded like or-patterns were completely unsupported. This error has an auto-fix suggestion that shows otherwise, but the auto-fix isn't always visible in IDEs. I've changed the wording to be consistent with "`Fn` bounds require arguments in parentheses", and it doesn't sound like a dead-end any more.
…ehuss Update the edition guide for let chains Pull rust-lang/edition-guide#337 into the rustc tree.
Enable non-leaf Frame Pointers for Arm64EC Windows This was enabled for native Arm64 via rust-lang#140828 r? `@workingjubilee`
…xyUwU Last minute relnotes fix This PR applies most of the suggestions in rust-lang#140802 (comment) (except for `as_flattened_mut`, which is indeed a const stabilization this cycle), and replaces all links from nightly to stable. r? ``@BoxyUwU``
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-run-make
Area: port run-make Makefiles to rmake.rs
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-release
Relevant to the release subteam, which will review and decide on the PR/issue.
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
T-rustdoc-frontend
Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.
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:
--doctest-compilation-args
with a simpler one:--doctest-build-arg
#139863 (rustdoc: Replace unstable flag--doctest-compilation-args
with a simpler one:--doctest-build-arg
)broken-pipe-no-ice
run-make test for rpath-less builds #140843 (Fixbroken-pipe-no-ice
run-make test for rpath-less builds)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup