Rollup of 7 pull requests by Dylan-DPC · Pull Request #112164 · rust-lang/rust

Dylan-DPC · 2023-06-01T05:39:45Z

Successful merges:

rustdoc: Fix LinkReplacer link matching #108459 (rustdoc: Fix LinkReplacer link matching)
Add a distinct OperandValue::ZeroSized variant for ZSTs #111318 (Add a distinct OperandValue::ZeroSized variant for ZSTs)
rustdoc: add interaction delays for tooltip popovers #111892 (rustdoc: add interaction delays for tooltip popovers)
Preserve substs in opaques recorded in typeck results #111980 (Preserve substs in opaques recorded in typeck results)
Don't suggest break through nested items #112024 (Don't suggest break through nested items)
Don't compute inlining status of mono items in advance. #112128 (Don't compute inlining status of mono items in advance.)
remove reference to Into in ? operator core/std docs, fix #111655 #112141 (remove reference to Into in ? operator core/std docs, fixstd incorrectly states that ? uses Into on the underlying error type #111655)

Failed merges:

Group rfcs tests #112071 (Group rfcs tests)

r? @ghost
@rustbot modify labels: rollup

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.

…typeck too

These tend to have special handling in a bunch of places anyway, so the variant helps remember that. And I think it's easier to grok than non-Scalar Aggregates sometimes being `Immediates` (like I got wrong and caused 109992). As a minor bonus, it means we don't need to generate poison LLVM values for them to pass around in `OperandValue::Immediate`s.

…tch, r=GuillaumeGomez rustdoc: Fix LinkReplacer link matching It currently just uses the first link with the same href which might not necessarily be the matching one. This fixes replacements when there are several links to the same item but with different text (e.g. `[X] and [struct@X]`). It also fixes replacements in summaries since those use a links list with empty hrefs, so currently all links would always match the first link by href but then not match its text. This could also lead to a panic in the `original_lext[1..len() - 1]` part when the first link only has a single character, which is why the new code uses `.get(..)` instead.

…ompiler-errors Add a distinct `OperandValue::ZeroSized` variant for ZSTs These tend to have special handling in a bunch of places anyway, so the variant helps remember that. And I think it's easier to grok than `Aggregate`s sometimes being `Immediates` (after all, I previously got that wrong and caused rust-lang#109992). As a minor bonus, it means we don't need to generate poison LLVM values for ZSTs to pass around in `OperandValue::Immediate`s. Inspired by rust-lang#110021 (comment), so r? `@compiler-errors`

…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

…=lcnr Preserve substs in opaques recorded in typeck results This means that we now prepopulate MIR with opaques with the right substs. The first commit is a hack that I think we discussed, having to do with `DefiningAnchor::Bubble` basically being equivalent to `DefiningAnchor::Error` in the new solver, so having to use `DefiningAnchor::Bind` instead, lol. r? `@lcnr`

…em, r=WaffleLapkin Don't suggest break through nested items Fixesrust-lang#112020

…=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``

…=thomcc remove reference to Into in ? operator core/std docs, fixrust-lang#111655 remove the text stating that `?` uses `Into::into` and add text stating it uses `From::from` instead. This closesrust-lang#111655.

Dylan-DPC · 2023-06-01T05:40:51Z

@bors r+ rollup=never p=5

bors · 2023-06-01T05:40:54Z

📌 Commit 129c559 has been approved by Dylan-DPC

It is now in the queue for this repository.

bors · 2023-06-01T08:06:10Z

⌛ Testing commit 129c559 with merge fabf929...

bors · 2023-06-01T10:47:03Z

☀️ Test successful - checks-actions
Approved by: Dylan-DPC
Pushing fabf929 to master...

rust-timer · 2023-06-01T10:49:04Z

📌 Perf builds for each rolled up PR:

PR#	Perf Build Sha
#112141	bc213ad50c0118dafa501c689391ad47fca2206c
#112128	086710b0d448db5ea4d89bc0a7a8f0c0f51da583
#112024	451a28eb81c86f15a6b668baa64ce679284d2293
#111980	49480f51f70bbbb64e76db2b719b57fd4f489d05
#111892	27f9b92b85ed530008c4dee2b2fdc33cca229ef7
#111318	0b1a91c5e6a933aa880d8e75b645f120a9bd3bab
#108459	3bee37ab9705856146371d8d59b4037fd40592aa

previous master: 23f93a1266

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

rust-timer · 2023-06-01T16:59:53Z

Finished benchmarking commit (fabf929): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.6%, 0.7%]	2
Regressions ❌ (secondary)	2.1%	[2.1%, 2.2%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.9%	[-3.1%, -2.7%]	2
All ❌✅ (primary)	0.6%	[0.6%, 0.7%]	2

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 642.933s -> 643.626s (0.11%)

Dylan-DPC · 2023-06-01T05:39:45Z

Successful merges:

rustdoc: Fix LinkReplacer link matching #108459 (rustdoc: Fix LinkReplacer link matching)
Add a distinct OperandValue::ZeroSized variant for ZSTs #111318 (Add a distinct OperandValue::ZeroSized variant for ZSTs)
rustdoc: add interaction delays for tooltip popovers #111892 (rustdoc: add interaction delays for tooltip popovers)
Preserve substs in opaques recorded in typeck results #111980 (Preserve substs in opaques recorded in typeck results)
Don't suggest break through nested items #112024 (Don't suggest break through nested items)
Don't compute inlining status of mono items in advance. #112128 (Don't compute inlining status of mono items in advance.)
remove reference to Into in ? operator core/std docs, fix #111655 #112141 (remove reference to Into in ? operator core/std docs, fixstd incorrectly states that ? uses Into on the underlying error type #111655)

Failed merges:

Group rfcs tests #112071 (Group rfcs tests)

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup