mirror of
https://github.com/rust-lang/rust.git
synced 2026-06-02 06:28:20 +03:00
Matthias Krüger
d6966fa15a
Fix invalid link generation for type alias methods Fixes https://github.com/rust-lang/rust/issues/149205. That one was quite the wild ride. First commit is the actual fix, the second commit is just a small name variable improvement while I was going through the code. Anyway, let's go through it: * We don't generate directly implementations in the HTML files for local impls (which I think is a mistake and should be changed, gonna do that as a follow-up) but instead generate a JS file for each type alias containing the HTML for these impls. * So in `write_shared.rs::TypeAliasPart::get`, when generating the JS file, we generate the impl into a `String` by calling `render_impl`. This method expects an `AssocItemLink` to help it generate the correct link to the item (I'm planning to also remove this enum because it's yet another way to generate anchors/hrefs). * Problem was: we call the `provided_trait_methods` method on the impl item... which is empty if not a trait impl. This becomes an issue when we arrive in `render::assoc_href_attr` because of this code: ```rust AssocItemLink::GotoSource(did, provided_methods) => { let item_type = match item_type { ItemType::Method | ItemType::TyMethod => { if provided_methods.contains(&name) { ItemType::Method } else { ItemType::TyMethod } } item_type => item_type, }; // ... } ``` Since `provided_methods` is always empty, it means all methods on type aliases will be `TyMethod`, generating `#tymethod.` URLs instead of `#method.`. * So generating `AssocItemLink::GoToSource` only on traits (when `provided_trait_methods` is supposed to return something) was the fix. * And finally, because it's (currently) generating implementations only through JS, it means we cannot test it in `tests/rustdoc` so I had to write the test in `tests/rustdoc-gui`. Once I change how we generate local implementations for type aliases, I'll move it to `tests/rustdoc`. r? ```@lolbinarycat```