Skip to content

Rollup of 5 pull requests #140844

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

Conversation

GuillaumeGomez
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

notriddle and others added 8 commits April 8, 2025 22:16
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>

![image](https://github.com/user-attachments/assets/9602380d-ad92-4b41-8070-e16659d7d445)

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 of "grip notching"](https://ux.stackexchange.com/questions/80463/what-do-the-3-close-horizontal-bars-not-hamburger-menu-represent-and-what-is-t/80591#80591):

- In Jira, resizable sidebars have a stack of four dots.

  <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
…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.
…e, r=oli-obk

Do not ICE when reassigning in GatherLocalsVisitor on the bad path

Fixes rust-lang#140785
Fixes rust-lang#140730

See comment in code.

r? oli-obk
@rustbot rustbot added 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-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. rollup A PR which is a rollup labels May 9, 2025
@GuillaumeGomez
Copy link
Member Author

Seems like the queue wasn't synced correctly...

@GuillaumeGomez GuillaumeGomez deleted the rollup-0og48s7 branch May 9, 2025 12:13
@rust-log-analyzer
Copy link
Collaborator

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

Click to see the possible cause of the failure (guessed by this bot)
#19 exporting to docker image format
#19 sending tarball 20.5s done
#19 DONE 26.3s
##[endgroup]
Setting extra environment values for docker:  --env ENABLE_GCC_CODEGEN=1 --env GCC_EXEC_PREFIX=/usr/lib/gcc/
[CI_JOB_NAME=x86_64-gnu-llvm-19]
[CI_JOB_NAME=x86_64-gnu-llvm-19]
debug: `DISABLE_CI_RUSTC_IF_INCOMPATIBLE` configured.
---
sccache: Listening on address 127.0.0.1:4226
##[group]Configure the build
configure: processing command line
configure: 
configure: build.configure-args := ['--build=x86_64-unknown-linux-gnu', '--llvm-root=/usr/lib/llvm-19', '--enable-llvm-link-shared', '--set', 'rust.randomize-layout=true', '--set', 'rust.thin-lto-import-instr-limit=10', '--set', 'build.print-step-timings', '--enable-verbose-tests', '--set', 'build.metrics', '--enable-verbose-configure', '--enable-sccache', '--disable-manage-submodules', '--enable-locked-deps', '--enable-cargo-native-static', '--set', 'rust.codegen-units-std=1', '--set', 'dist.compression-profile=balanced', '--dist-compression-formats=xz', '--set', 'rust.lld=false', '--disable-dist-src', '--release-channel=nightly', '--enable-debug-assertions', '--enable-overflow-checks', '--enable-llvm-assertions', '--set', 'rust.verify-llvm-ir', '--set', 'rust.codegen-backends=llvm,cranelift,gcc', '--set', 'llvm.static-libstdcpp', '--set', 'gcc.download-ci-gcc=true', '--enable-new-symbol-mangling']
configure: build.build          := x86_64-unknown-linux-gnu
configure: target.x86_64-unknown-linux-gnu.llvm-config := /usr/lib/llvm-19/bin/llvm-config
configure: llvm.link-shared     := True
configure: rust.randomize-layout := True
configure: rust.thin-lto-import-instr-limit := 10
---
test [ui] tests/ui/wrong-hashset-issue-42918.rs ... ok

failures:

---- [ui] tests/ui/typeck/gather-locals-twice.rs stdout ----
Saved the actual stderr to "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/typeck/gather-locals-twice/gather-locals-twice.stderr"
diff of stderr:

1 error[E0368]: binary assignment operation `+=` cannot be applied to type `()`
-   --> $DIR/gather-locals-twice.rs:2:5
+   --> $DIR/gather-locals-twice.rs:4:5
3    |
4 LL |     () += { let x; };
5    |     --^^^^^^^^^^^^^^

7    |     cannot use `+=` on type `()`
8 
9 error[E0067]: invalid left-hand side of assignment
-   --> $DIR/gather-locals-twice.rs:2:8
+   --> $DIR/gather-locals-twice.rs:4:8
11    |
12 LL |     () += { let x; };
13    |     -- ^^

Note: some mismatched output was normalized before being compared
-   --> /checkout/tests/ui/typeck/gather-locals-twice.rs:4:5
-   --> /checkout/tests/ui/typeck/gather-locals-twice.rs:4:8
---
To only update this specific test, also pass `--test-args typeck/gather-locals-twice.rs`

error: 1 errors occurred comparing output.
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/typeck/gather-locals-twice.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2" "--target=x86_64-unknown-linux-gnu" "--check-cfg" "cfg(test,FALSE)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/typeck/gather-locals-twice" "-A" "unused" "-A" "internal_features" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers"
stdout: none
--- stderr -------------------------------
error[E0368]: binary assignment operation `+=` cannot be applied to type `()`
##[error]  --> /checkout/tests/ui/typeck/gather-locals-twice.rs:4:5
   |
LL |     () += { let x; };
   |     --^^^^^^^^^^^^^^
   |     |
   |     cannot use `+=` on type `()`

error[E0067]: invalid left-hand side of assignment
##[error]  --> /checkout/tests/ui/typeck/gather-locals-twice.rs:4:8
   |
LL |     () += { let x; };
   |     -- ^^
   |     |
   |     cannot assign to this expression

error: aborting due to 2 previous errors

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. T-compiler Relevant to the compiler team, 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants