This code was added in 9dc5dfb975
and 704050da23 because the browser-
native checkbox was `display: none`, breaking native keyboard
accessibility.
The native checkbox is now merely `appearance: none`, which does
not turn off [behavior semantics], so JavaScript to
reimplement it isn't needed any more.
[behavior semantics]: https://w3c.github.io/csswg-drafts/css-ui/#appearance-semantics
Spelling librustdoc
This is split from https://github.com/rust-lang/rust/pull/110392
There's one change to src/tools/rustdoc-gui/tester.js which feels like a reasonable thing to piggy-back here.
rustdoc: stop passing a title to `replaceState` second argument
As described on [MDN's replaceState page], this parameter is not currently used, and the empty string is "safe against future changes to the method."
[MDN's replaceState page]: https://developer.mozilla.org/en-US/docs/Web/API/History/replaceState
rustdoc-search: add support for nested generics
This change allows `search.js` to parse nested generics (which look `Like<This<Example>>`) and match them. It maintains the existing "bag semantics", so that the order of type parameters is ignored but the number is required to be greater than or equal to what's in the query.
For example, a function with the signature `fn read_all(&mut self: impl Read) -> Result<Vec<u8>, Error>` will match these queries:
* `Read -> Result<Vec<u8>, Error>`
* `Read -> Result<Error, Vec>`
* `Read -> Result<Vec<u8>>`
But it *does not* match `Result<Vec, u8>` or `Result<u8<Vec>>`.
Fixes the desktop scrolling weirdness mentioned in
https://github.com/rust-lang/rust/pull/98775#issuecomment-1182575603
As described in the MDN page for this property:
* The current Firefox ESR is 102, and the first Firefox version
to support this feature is 59.
* The current Chrome version 112, and the first version to support
this is 63.
* Edge is described as having a minor bug in `none` mode, but we
use `contain` mode anyway, so it doesn't matter.
* Safari 16, released September 2022, is the last browser to
add this feature, and is also the oldest version we officially
support.
This is very dependent on subjectivity and what screen you use,
but this change makes the radio buttons' outer circle less ugly.
This is because I could see the pixels very clearly, thanks to the
very thin line and high contrast. This change makes both less
severe, giving your browser's antialiasing algorithm more to
work with. Since it's thicker, lowering the contrast shouldn't
impact visibility.
rustdoc: remove redundant expandSection code from main.js
This functionality is already tested in `hash-item-expansion.goml`, and was implemented twice:
* First, in code that ran at load time and at hash change: 917cdd295d
* Later, the hash change event handler was itself run at load time, and the code handling both cases diverged in implementation, though their behavior still matches pretty well: f66a331335
This functionality is already tested in `hash-item-expansion.goml`,
and was implemented twice:
* First, in code that ran at load time and at hash change:
917cdd295d
* Later, the hash change event handler was itself run at load time,
and the code handling both cases diverged in implementation,
though their behavior still matches pretty well:
f66a331335
* Stop checking `func` in `onEach`. It's always hard-coded right
at the call site, so there's no point.
* Use the ternary operator in a few spots where it makes sense.
* No point in making `onEach` store `arr.length` in a variable if
it's only used once anyway.
rustdoc: escape GAT args in more cases
Fixes#109488.
Previously we printed the *un*escaped form of GAT arguments not only when `f.alternate()` was true but *also* when we failed to compute the URL of the trait associated with the type projection, i.e. when `href(…)` returned an `Err(_)`.
In this PR the argument printing logic is entirely separate from the link resolution code above as it should be.
Further, we now only try to compute the URL if the HTML format was requested with `!f.alternate()`. Before, we would sometimes compute the `href` only to throw it away later.
Fix "Directly go to item in search if there is only one result" setting
Part of #66181.
The setting was actually broken, so I fixed it when I added the GUI test.
r? `@notriddle`
rustdoc: Optimize impl sorting during rendering
This should fix the perf regression on [bitmaps-3.1.0](https://github.com/rust-lang/rustc-perf/tree/master/collector/compile-benchmarks/bitmaps-3.1.0) from https://github.com/rust-lang/rust/pull/107765.
The bitmaps crate has a lot of impls:
```rust
impl Bits for BitsImpl<1> { ... }
impl Bits for BitsImpl<2> { ... }
// ...
impl Bits for BitsImpl<1023> { ... }
impl Bits for BitsImpl<1024> { ... }
```
and the logic in `fn print_item` sorts them in natural order.
Before https://github.com/rust-lang/rust/pull/107765 the impls came in source order, which happened to be already sorted in the necessary way.
So the comparison function was called fewer times.
After https://github.com/rust-lang/rust/pull/107765 the impls came in "stable" order (based on def path hash).
So the comparison function was called more times to sort them.
The comparison function was terribly inefficient, so it caused a large perf regression.
This PR attempts to make it more efficient by using cached keys during sorting.
rustdoc: add support for type filters in arguments and generics
This makes sense, since the search index has the information in it, and it's more useful for function signature searches since a function signature search's item type is, by definition, some type of function (there's more than one, but not very many).
