rustdoc: Sort implementors

[kzys]

Fixes #53812

[rust-highfive]

r? @steveklabnik

(rust_highfive has picked a reviewer for you, use r? to override)

[kzys]

Sorry, it shouldn't have the submodules. The latest commit doesn't have them.

[kzys]

r? @QuietMisdreavus @GuillaumeGomez

[GuillaumeGomez]

Thanks!

The lack of test is problematic though, but you can't really add one since the UI tests are still pending... Should we wait the merge of the UI tests PR @QuietMisdreavus?

[kzys]

I'm fine with waiting #53319.

[TimNN]

Ping from triage @GuillaumeGomez: It looks like we won't be able to run the UI tests on CI soon. Do you still want to mark this PR as blocked on it? Otherwise, this PR requires your review.

[GuillaumeGomez]

This is really problematic... Code seems good but we have no way to ensure that it won't break later in the future... If everyone's fine with that, then r=me.

[bors]

☔ The latest upstream changes (presumably #54146) made this pull request unmergeable. Please resolve the merge conflicts.

[kzys]

How about adding tests under src/test/rustdoc/? Seems like I can validate something like "the first element under this element must be X".

[GuillaumeGomez]

Let's go for this then...

[QuietMisdreavus]

Testing something like "the first element in this list must be X" should fit into a src/test/rustdoc test, since the XPath implementation we use should be able to support that:

rust/src/etc/htmldocck.py

Lines 67 to 97 in 994cdd9

	* `@has PATH XPATH PATTERN` and `@matches PATH XPATH PATTERN` checks for
	the presence of given `XPATH` in the given HTML file, and also
	the occurrence of given `PATTERN` in the matching node or attribute.
	Only one occurrence of given pattern in the match is enough.
	`PATH` should be a valid and well-formed HTML file. It does *not*
	accept arbitrary HTML5; it should have matching open and close tags
	and correct entity references at least.
	`XPATH` is an XPath expression to match. This is fairly limited:
	`tag`, `*`, `.`, `//`, `..`, `[@attr]`, `[@attr='value']`, `[tag]`,
	`[POS]` (element located in given `POS`), `[last()-POS]`, `text()`
	and `@attr` (both as the last segment) are supported. Some examples:
	- `//pre` or `.//pre` matches any element with a name `pre`.
	- `//a[@href]` matches any element with an `href` attribute.
	- `//*[@class="impl"]//code` matches any element with a name `code`,
	which is an ancestor of some element which `class` attr is `impl`.
	- `//h1[@class="fqn"]/span[1]/a[last()]/@class` matches a value of
	`class` attribute in the last `a` element (can be followed by more
	elements that are not `a`) inside the first `span` in the `h1` with
	a class of `fqn`. Note that there cannot be no additional elements
	between them due to the use of `/` instead of `//`.
	Do not try to use non-absolute paths, it won't work due to the flawed
	ElementTree implementation. The script rejects them.
	For the text matches (i.e. paths not ending with `@attr`), any
	subelements are flattened into one string; this is handy for ignoring
	highlights for example. If you want to simply check the presence of
	given node or attribute, use an empty string (`""`) as a `PATTERN`.

I'd be okay with a test that did that.

[GuillaumeGomez]

With such a test, it'd be as good as a UI one. Thanks for the head up @QuietMisdreavus!

[kzys]

Hmm, is there a way to have the test file as std?

pub trait MyIterator {
}

macro_rules! array_impls {
    ($($N:expr)+) => {
        $(
            impl<'a, T> MyIterator for &'a mut [T; $N] {
            }
        )+
    }
}

array_impls! { 0 1 2 }

The above is built as its own crate, which makes all MyIterator implementations as Implementations on Foreign Types. And the section somehow doesn't have this problem. In other words, I can't repro the issue in this test.

[QuietMisdreavus]

Try using a wrapper type instead of plain arrays:

pub trait MyIterator {
}

pub struct MyStruct<T>(T);

macro_rules! array_impls {
    ($($N:expr)+) => {
        $(
            impl<'a, T> MyIterator for MyStruct<&'a mut [T; $N]> {
            }
        )+
    }
}

array_impls! { 0 1 2 }

That should make rustdoc treat the implementation as on a local type.

[GuillaumeGomez]

Please check h3[2], h3[3] and h3[4] too. Like that we're sure it's not just luck.

[GuillaumeGomez]

Thanks!

@bors: r+ rollup

[bors]

📌 Commit 2fe4503 has been approved by GuillaumeGomez