Simplify codeblock and their associated tooltip
It is based on https://github.com/rust-lang/rust/pull/101600 so it needs to wait for this one to be merged first.
This PR does two things:
* Remove CSS class duplication by setting CSS classes such as `compile_fail` directly on the `div` wrapping both the codeblock and the tooltip.
* Simplify DOM: no need to wrap the tooltip into a `<div>`, it can work just as well without it.
You can test it [here](https://rustdoc.crud.net/imperio/codeblock-tooltip/std/string/struct.String.html#deref).
r? `@notriddle`
Equate fn outputs when inferring RPITIT hidden types
When we are trying to infer the hidden types for RPITITs, we need to equate the output tys instead of just subtyping them. For example:
```rust
trait Foo { fn bar() -> impl Sized {} }
impl Foo for () { fn bar() -> &'static str { "" } }
```
If we just subtype the signatures `fn() -> &'static str <: fn() -> _#1t` (where `_#1t` is the variable we've used to infer `impl Sized`), we'll end up `&'static str <: _#1t`, which causes us to infer `_#1t = #'_#2r str`, where `'_#2r` is unconstrained, which gets fixed up to `ReEmpty`, and which is certainly not what we want.
I can't actually think of a way to make this fail to compile, because during borrowck we've already done the method probe, and so we just look at the `impl` method signature and see the `&'static str` any time we call `<() as Foo>::bar()`. But this _does_ cause the ICE [here](https://github.com/rust-lang/rust/pull/98559#issuecomment-1241891994) in `@jackh726's` "Remove ReEmpty" PR (#98559) to stop ICEing, because after that PR we were leaking unconstrained region variables into the typeck results.
r? types
The `<*const T>::guaranteed_*` methods now return an option for the unknown case
cc https://github.com/rust-lang/rust/issues/53020#issuecomment-1236932443
I chose `0` for "not equal" and `1` for "equal" and left `2` for the unknown case so backends can just forward to raw pointer equality and it works ✨
r? `@fee1-dead` or `@lcnr`
cc `@rust-lang/wg-const-eval`
Rustdoc-Json: Correcty handle intra-doc-links to items without HTML page
Closes#101531
I renamed the `did` field in `ItemLink ` to more accurately describe what it does.
r? `@jyn514`
rustdoc: remove unused CSS `#search { position: relative }`
This was added in 611d0e6cce, to allow its child `#results` element to be absolutely positioned inside it. The child stopped being absolute in 8c0469552e.
To keep the layout looking the same, the links need to not have `width: 100%` any more, relying instead on the box naturally growing to fit because it has `display: block`.
Fix ICE report flags display.
#92310 made some changes to the ICE report that displays the rustc flags, but it introduced a bug where a flag like `-Z incremental-verify-ich=yes` was being treated as-if it was `-Cincremental`. This corrupted the output and made it confusing. The cause was using `starts_with` instead of properly splitting the option.
For example, with the command like `rustc foo.rs -Cincremental=/tmp/a -Zincremental-verify-ich=yes --crate-type lib` would previously look like:
```
note: compiler flags: -C incremental -Z incremental --crate-type lib
```
It now looks like:
```
note: compiler flags: -C incremental=[REDACTED] -Z incremental-verify-ich=yes --crate-type lib
```
I added a `[REDACTED]` marker for `-Cincremental` so it is a little less confusing that a value has been removed.
Fixes#101588
Stabilize raw-dylib for non-x86
This stabilizes the `raw-dylib` and `link_ordinal` features (#58713) for non-x86 architectures (i.e., `x86_64`, `aarch64` and `thumbv7a`):
* Marked the `raw_dylib` feature as `active`.
* Marked the `link_ordinal` attribute as `ungated`.
* Added new errors if either feature is used on x86 targets without the `raw_dylib` feature being enabled.
* Updated tests to only set the `raw_dylib` feature when building for x86.
Rollup of 5 pull requests
Successful merges:
- #101366 (Restore old behaviour on broken UNC paths)
- #101492 (Suggest adding array lengths to references to arrays if possible)
- #101529 (Fix the example code and doctest for Formatter::sign_plus)
- #101573 (update `ParamKindOrd`)
- #101612 (Fix code generation of `Rvalue::Repeat` with 128 bit values)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Rollup of 5 pull requests
Successful merges:
- #101475 (Use futex-based locks and thread parker on Hermit)
- #101492 (Suggest adding array lengths to references to arrays if possible)
- #101495 (Compile spin_loop_hint as pause on x86 even without sse2 enabled)
- #101529 (Fix the example code and doctest for Formatter::sign_plus)
- #101600 (rustdoc: simplify the codeblock tooltip)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
This was added in 611d0e6cce, to allow its
child `#results` element to be absolutely positioned inside it. The
child stopped being absolute in 8c0469552e.
To keep the layout looking the same, the links need to not have
`width: 100%` any more, relying instead on the box naturally growing to
fit because it has `display: block`.
Fix the example code and doctest for Formatter::sign_plus
The provided example to the `sign_plus` method on `fmt` was broken, it displays the `-` sign twice for negative numbers.
This pull request should fix the issue by `.abs()` ing the number so that the negative sign appears only once. It is just one possible solution to the issue, not sure if it's the best. However, this one will behave as expected when combined with fill and alignment operators.
Restore old behaviour on broken UNC paths
This fixes#101358 by restoring the behaviour from previous stable Rust versions. I'm not convinced this is ultimately right but I think it's less wrong and maybe this should be backported to beta?
r? libs
rustdoc: simplify the codeblock tooltip
**https://github.com/rust-lang/rust/pull/101593 needs merged first**
This PR moves the tooltip into example-wrap, simplifying several overly-complex aspects of how these tooltips work:
* The mousover javascript can be removed, because hovering example-wrap can style the tooltip inside.
* The sibling selecor can be removed, because hovering the tooltip also hovers the wrapper, which can hover the codeblock itself.
* The relative positioning of the `<li>` tag, which was added in e861efd9f9 to fix the positioning of the code tooltip, can now be removed, because example-wrap itself already has relative positioning.
