-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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 7 pull requests #112159
Closed
Closed
Rollup of 7 pull requests #112159
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
Previously, this would print a message for each doctest, which was quite verbose: ``` doc tests for: /home/jyn/src/rust/src/doc/rustc/src/exploit-mitigations.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/instrument-coverage.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/json.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/linker-plugin-lto.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/lints/groups.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/lints/index.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/lints/levels.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/aarch64-apple-ios-sim.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/aarch64-nintendo-switch-freestanding.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/apple-watchos.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/armeb-unknown-linux-gnueabi.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/armv4t-none-eabi.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/armv5te-none-eabi.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/armv6k-nintendo-3ds.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/armv7-sony-vita-newlibeabihf.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/armv7-unknown-linux-uclibceabi.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/armv7-unknown-linux-uclibceabihf.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/esp-idf.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/fuchsia.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/kmc-solid.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/loongarch-linux.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/m68k-unknown-linux-gnu.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/mipsel-sony-psx.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/nto-qnx.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/openbsd.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/openharmony.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/riscv32imac-unknown-xous-elf.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/unknown-uefi.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/wasm64-unknown-unknown.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/x86_64-fortanix-unknown-sgx.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/x86_64-unknown-none.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/profile-guided-optimization.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/target-tier-policy.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/targets/custom.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/targets/index.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/tests/index.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/what-is-rustc.md ```
Designing a good hover microinteraction is a matter of guessing user intent from what are, literally, vague gestures. In this case, guessing if hovering in our out of the tooltip base is intentional or not. To figure this out, a few different techniques are used: * When the mouse pointer enters a tooltip anchor point, its hitbox is grown on the bottom, where the popover is/will appear. This was already there before this commit: search "hover tunnel" in rustdoc.css for the implementation. * This commit adds a delay when the mouse pointer enters the base anchor, in case the mouse pointer was just passing through and the user didn't want to open it. * This commit also adds a delay when the mouse pointer exits the tooltip's base anchor or its popover, before hiding it. * A fade-out animation is layered onto the pointer exit delay to immediately inform the user that they successfully dismissed the popover, while still providing a way for them to cancel it if it was a mistake and they still wanted to interact with it. * No animation is used for revealing it, because we don't want people to try to interact with an element while it's in the middle of fading in: either they're allowed to interact with it while it's fading in, meaning it can't serve as mistake- proofing for opening the popover, or they can't, but they might try and be frustrated. See also: * https://www.nngroup.com/articles/timing-exposing-content/ * https://www.nngroup.com/articles/tooltip-guidelines/ * https://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown
We record inlining status for mono items in `MonoItems`, and then transfer it to `InliningMap`, for later use in `InliningMap::with_inlining_candidates`. But we can just compute inlining status directly in `InliningMap::with_inlining_candidates`, because the mono item is right there. There's no need to compute it in advance. This commit changes the code to do that, removing the need for `MonoItems` and `InliningMap::inlines`. This does result in more calls to `instantiation_mode` (one per static occurrence) but the performance effect is negligible.
This fixes the behavior of sending EOF by pressing Ctrl+Z => Enter in a windows console. Previously, that would trip the unpaired surrogate error, whereas now we correctly detect EOF.
Make `x test --dry-run` less verbose The new output looks like `Testing stage2 book rustc (x86_64-unknown-linux-gnu)`. Previously, this would print a message for each doctest, which was quite verbose: ``` doc tests for: /home/jyn/src/rust/src/doc/rustc/src/exploit-mitigations.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/instrument-coverage.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/json.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/linker-plugin-lto.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/lints/groups.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/lints/index.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/lints/levels.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/aarch64-apple-ios-sim.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/aarch64-nintendo-switch-freestanding.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/apple-watchos.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/armeb-unknown-linux-gnueabi.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/armv4t-none-eabi.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/armv5te-none-eabi.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/armv6k-nintendo-3ds.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/armv7-sony-vita-newlibeabihf.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/armv7-unknown-linux-uclibceabi.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/armv7-unknown-linux-uclibceabihf.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/esp-idf.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/fuchsia.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/kmc-solid.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/loongarch-linux.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/m68k-unknown-linux-gnu.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/mipsel-sony-psx.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/nto-qnx.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/openbsd.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/openharmony.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/riscv32imac-unknown-xous-elf.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/unknown-uefi.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/wasm64-unknown-unknown.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/x86_64-fortanix-unknown-sgx.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/platform-support/x86_64-unknown-none.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/profile-guided-optimization.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/target-tier-policy.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/targets/custom.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/targets/index.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/tests/index.md doc tests for: /home/jyn/src/rust/src/doc/rustc/src/what-is-rustc.md ```
…p, r=me,GuillaumeGomez,Manishearth rustdoc: add interaction delays for tooltip popovers Preview: * [notable traits](http://notriddle.com/rustdoc-demo-html-3/delay-tooltip/testing/struct.Vec.html#method.iter) * [panicking code block](http://notriddle.com/rustdoc-demo-html-3/delay-tooltip/testing/struct.Vec.html#indexing) Designing a good hover microinteraction is a matter of guessing user intent from what are, literally, vague gestures. In this case, guessing if hovering in our out of the tooltip base is intentional or not. To figure this out, a few different techniques are used: * When the mouse pointer enters a tooltip anchor point, its hitbox is grown on the bottom, where the popover is/will appear. This was already there before this commit: search "hover tunnel" in rustdoc.css for the implementation. * This commit adds a delay when the mouse pointer enters the base anchor, in case the mouse pointer was just passing through and the user didn't want to open it. * This commit also adds a delay when the mouse pointer exits the tooltip's base anchor or its popover, before hiding it. * A fade-out animation is layered onto the pointer exit delay to immediately inform the user that they successfully dismissed the popover, while still providing a way for them to cancel it if it was a mistake and they still wanted to interact with it. * No animation is used for revealing it, because we don't want people to try to interact with an element while it's in the middle of fading in: either they're allowed to interact with it while it's fading in, meaning it can't serve as mistake- proofing for opening the popover, or they can't, but they might try and be frustrated. See also: * https://www.nngroup.com/articles/timing-exposing-content/ * https://www.nngroup.com/articles/tooltip-guidelines/ * https://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown
…=wesleywiser Don't compute inlining status of mono items in advance. We record inlining status for mono items in `MonoItems`, and then transfer it to `InliningMap`, for later use in `InliningMap::with_inlining_candidates`. But we can just compute inlining status directly in `InliningMap::with_inlining_candidates`, because the mono item is right there. There's no need to compute it in advance. This commit changes the code to do that, removing the need for `MonoItems` and `InliningMap::inlines`. This does result in more calls to `instantiation_mode` (one per static occurrence) but the performance effect is negligible. r? `@wesleywiser`
…lor-10, r=notriddle Migrate GUI colors test to original CSS color format Follow-up of rust-lang#111459. r? `@notriddle`
…=thomcc remove reference to Into in ? operator core/std docs, fix rust-lang#111655 remove the text stating that `?` uses `Into::into` and add text stating it uses `From::from` instead. This closes rust-lang#111655.
…er-errors add inline-const test for elided lifetimes being infer vars Fixes rust-lang#110934
…omcc Fix bug in utf16_to_utf8 for zero length strings This fixes the behavior of sending EOF by pressing Ctrl+Z => Enter in a windows console. Previously, that would trip the unpaired surrogate error, whereas now we correctly detect EOF.
@bors r+ rollup=never p=7 |
⌛ Testing commit 953f849 with merge baadc50cccf4c7f90f531dd4618143e714ee7c3b... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
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-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library 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.
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:
x test --dry-run
less verbose #111802 (Makex test --dry-run
less verbose)?
usesInto
on the underlying error type #111655)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup