Additional docs on pub re-exports resolve intra-doc links relative to the original module

[jyn514]

I tried this code:

/// I want to show [with_code]
pub use std::string::String;

pub fn with_code() {}

I expected to see this happen: Rustdoc links all the original documentation relative to std::string, and all the new documentation relative to the current crate, so with_code resolves properly.

Instead, this happened: Rustdoc links all the original documentation relative to std::string:

Sep 26 22:41:10.388  INFO rustdoc::passes::collect_intra_doc_links: ignoring warning from parent crate: unresolved link to `with_code`

This hits proc-macros especially hard because they're forced to be in a separate crate and can't link to anything in the main crate.

Meta

rustdoc --version: rustdoc 1.48.0-nightly (f68e089 2020-09-19), but also present on master (1ec980d)

[jyn514]

Originally I thought this would need pulldown support, but I might be able to hack it by using the span of the BrokenLink pulldown returns.

[jyn514]

I'm not sure it's possible to go from a Span to the module it's defined in :/

[jyn514]

Another possible approach is to use the DefId of the use statement itself, but that requires fixing #77230 first.

[jyn514]

Originally I thought this would need pulldown support, but I might be able to hack it by using the span of the BrokenLink pulldown returns.

It turns out pulldown already has this support in the form of into_offset_iter.

[jyn514]

So I don't forget, this is my current progress:

• Refactor DocFragments; this was simple and necessary to add the HirId for the docs (Change DocFragments from enum variant fields to structs with a nested enum #77513)
• Require a HirId for try_inline. This was not too painful but not very useful in itself. It does not currently handle multiple re-exports, I just have an unimplemented!() (not published).
• Take an optional HirId in merge_attrs. This is necessary but not sufficient for keeping track of the HirId for the attrs.
• Take an optional HirId in Attributes::from_ast; again, necessary but not sufficient.

The issue I currently have is that attributes are combined before calling from_ast, and I'm not sure how to work merging attrs into from_ast. Maybe it could take attrs: &[ast::Attribute] and other_attrs: &[...], plus a HirId for both? That seems not too painful; I'll need to slightly refactor from_ast to allow doing the same inner actions for two different lists. I have no idea how to generalize this to arbitrary re-exports - maybe Vec<(&[ast::Attribute], HirId)>?

[jyn514]

The painful thing is going to be working this into impl Clean<Attributes> for [ast::Attribute] - Clean doesn't allow taking any additional parameters and turning it into a free function instead causes about 30 non-trivial errors.

[jyn514]

Actually this might work - the original HirId will always correspond to the DefId, so it can just be none. Then any following attributes will make the HirId mandatory. 🤞

[jyn514]

A new problem: collapse_docs turns all attributes into one giant attribute 🤦 @GuillaumeGomez do you know what that's for? Is it safe to just get rid of it and insert newlines between docs instead?

[GuillaumeGomez]

I think it's to merge both #[doc = "..."] and /// attributes.