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 7 pull requests #112159

Closed
wants to merge 16 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

jyn514 and others added 16 commits May 20, 2023 10:53
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.
@rustbot rustbot added 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. rollup A PR which is a rollup labels Jun 1, 2023
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=7

@bors
Copy link
Contributor

bors commented Jun 1, 2023

📌 Commit 953f849 has been approved by matthiaskrgr

It is now in the queue for this repository.

@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 Jun 1, 2023
@bors
Copy link
Contributor

bors commented Jun 1, 2023

⌛ Testing commit 953f849 with merge baadc50cccf4c7f90f531dd4618143e714ee7c3b...

@rust-log-analyzer
Copy link
Collaborator

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

Click to see the possible cause of the failure (guessed by this bot)
test sync::mpsc::tests::stress_recv_timeout_two_threads ... ok

failures:

---- sys::windows::process::tests::test_thread_handle stdout ----
thread 'sys::windows::process::tests::test_thread_handle' panicked at 'assertion failed: res.unwrap().is_some()', library\std\src\sys\windows\process\tests.rs:48:5

failures:
    sys::windows::process::tests::test_thread_handle


test result: FAILED. 902 passed; 1 failed; 4 ignored; 0 measured; 0 filtered out; finished in 12.93s

error: test failed, to rerun pass `-p std --lib`
Build completed unsuccessfully in 0:52:09
make: *** [Makefile:78: ci-mingw-subset-1] Error 1

@bors
Copy link
Contributor

bors commented Jun 1, 2023

💔 Test failed - checks-actions

@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 Jun 1, 2023
@matthiaskrgr matthiaskrgr deleted the rollup-0eh9v4w branch March 16, 2024 18:18
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

std incorrectly states that ? uses Into on the underlying error type