rustdoc: emit JS paths for struct-like variants

[tomjakubowski]

On the backend, rustdoc now emits paths entries to a crate's search
index for struct-like enum variants, and index items of type structfield
which belong to such variants point to their variant parents in the
paths table, rather than their enum grandparents. The path entry for
a variant is the fully qualified module path plus the enum name.

On the frontend, the search code recognizes structfields belonging to
structlike variants in the paths table and re-constructs the URL to
the field's anchor on the enum documentation page.

closes #16017

[tomjakubowski]

Before and after, same test crate.

Wrong display path, wrong URL (note extra Foo).

Right display path, right URL.

#![no_std]
#![crate_type = "lib"]

pub mod xxx {
    pub enum Foo {
        TupleVrnt(u8),
        Vrnt { baz: i32 },
        Vrnt2 { quux: f32 },
    }

    pub struct SFoo {
        pub sbaz: (),
    }
}

---

I'd like to add tests for this, but I could use help with how to write them. There are three major changes:

1. Variants themselves are now emitted to the paths table when they have structfield children. It's hard to write this test with the only tool I know, a compiletest like @has search-index.js, because the test should verify that the variant name specifically appear in the paths table (without these changes, the variant's name would still appear in the search index items).
2. Such variant-residing structfield search index items now point to the variant as their parent, rather than to the enum. Same problem as above - hard to test for this with @has search-index.js.
3. The search code's render function buildHrefAndPath() is fixed to handle the peculiar structfield-variant case. I haven't ever written a test for the rustdoc frontend so I wouldn't know where to begin. src/test/rustdoc-js seems to be specialized for testing search queries.

[Mark-Simulacrum]

For e.g. core or std, how much of a size increase is this?

[tomjakubowski]

I'll measure to be sure, but was careful (at least, tried to be!) to make this "zero cost"* in size of search-index.js for crates that don't use struct variants, and I believe that core/std only has tuple-like variants in public enums.

*: Rustdoc prunes entries from the paths table that are unreferenced by search index items, i.e., any variants which don't have structfields shouldn't appear in the paths table.

[bors]

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

[tomjakubowski]

I ran ./x.py doc --stage 1 for fb74e62 and the master branch commit I based on, eb48d6b.

% tar tzvf docs-my-patch.tar.gz | grep search-index                                       
-rw-r--r-- tom/tom     1495263 2019-09-25 17:02 build/x86_64-unknown-linux-gnu/doc/search-index1.39.0.js

% tar tzvf docs-master-eb48d6bdee6c655d71f26594d47d232adf3e4e93.tar.gz | grep search-index
-rw-r--r-- tom/tom     1495143 2019-09-26 13:15 build/x86_64-unknown-linux-gnu/doc/search-index1.39.0.js

So the search index has a size increase of 220 bytes or 0.015%.

[tomjakubowski]

The extra bytes come from adding a path for this variant: https://doc.rust-lang.org/nightly/std/collections/enum.TryReserveError.html#variant.AllocError

[Mark-Simulacrum]

That size increase looks entirely reasonable :)

Thanks for investigating!

[JohnCSimon]

Ping from triage.
This PR has sat idle for the last 9 days
@tomjakubowski can you please address the merge conflict?
CC @Mark-Simulacrum @QuietMisdreavus
Thank you!

[JohnCSimon]

Pinging again from triage.
This PR has sat idle for the last 15 days
@tomjakubowski can you please address the merge conflict?
CC @Mark-Simulacrum @QuietMisdreavus
Thank you!

[joelpalmer]

Ping from Triage: Closing due to inactivity. @tomjakubowski please reopen with any updates. Thanks for the PR.