Implement negative bounds for internal testing purposes
Implements partial support the `!` negative polarity on trait bounds. This is incomplete, but should allow us to at least be able to play with the feature.
Not even gonna consider them as a public-facing feature, but I'm implementing them because would've been nice to have in UI tests, for example in #110671.
Currently a `{D,Subd}iagnosticMessage` can be created from any type that
impls `Into<String>`. That includes `&str`, `String`, and `Cow<'static,
str>`, which are reasonable. It also includes `&String`, which is pretty
weird, and results in many places making unnecessary allocations for
patterns like this:
```
self.fatal(&format!(...))
```
This creates a string with `format!`, takes a reference, passes the
reference to `fatal`, which does an `into()`, which clones the
reference, doing a second allocation. Two allocations for a single
string, bleh.
This commit changes the `From` impls so that you can only create a
`{D,Subd}iagnosticMessage` from `&str`, `String`, or `Cow<'static,
str>`. This requires changing all the places that currently create one
from a `&String`. Most of these are of the `&format!(...)` form
described above; each one removes an unnecessary static `&`, plus an
allocation when executed. There are also a few places where the existing
use of `&String` was more reasonable; these now just use `clone()` at
the call site.
As well as making the code nicer and more efficient, this is a step
towards possibly using `Cow<'static, str>` in
`{D,Subd}iagnosticMessage::{Str,Eager}`. That would require changing
the `From<&'a str>` impls to `From<&'static str>`, which is doable, but
I'm not yet sure if it's worthwhile.
rustdoc: Get `repr` information through `AdtDef` for foreign items
As suggested by `@notriddle,` this approach works too. The only downside is that the display of the original attribute isn't kept, but I think it's an acceptable downside.
r? `@notriddle`
In the old setup, if the dereffed-to item has multiple impl blocks,
each one gets its own `div.impl-items` in the section, but there
are no headers separating them. Since the last method in a
`div.impl-items` has no bottom margin, and there are no margins
between these divs, there is no margin between the last method
of one impl and the first method of the following impl.
This patch fixes it by simplifying the HTML. Each Deref block gets
exactly one `div.impl-items`, no matter how many impl blocks it
actually has.
rustdoc: clean up settings.css and settings.js
`handleKey` 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
The other, one line change to settings.css is follow-up to #110205
rustdoc: clean up JS
* use `Set` for ignored crates in cross-crate trait impl JS, instead of `indexOf` string manipulation
* lift constant `window.location.split` code out of a loop in source code sidebar builder
* remove redundant history manipulation from search page exit
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
* There's no need to call `history.replaceState` right before
calling `searchState.hideResults`, which already does it.
* There's no need to implement hiding search results when that
is already implemented.
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.
