[rustdoc] partially fix invalid files creation

[GuillaumeGomez]

Part of #111249. It only removes generation for modules which shouldn't exist. For files, we need the compiler to keep re-export information alive for external items so we can actually have the right path to their location as it's currently not generating them correctly.

In case the item is inlined, it shouldn't (and neither should its children) get a file generated.

r? @notriddle

[rustbot]

Some changes occurred in src/librustdoc/clean/types.rs

cc @camelid

[GuillaumeGomez]

Found out the issue: it's because of re-exports, as usual. ParseFloatError is re-exported from dec2flt because this module is private. However, dependencies don't know about that. The usual issue in short. Trying to find if there is a way to go around that, otherwise I'll have to revert some parts of this PR.

[notriddle]

However, dependencies don't know about that.

Awhile ago, I looked through a bunch of diagnostics code and found the infrastructure that the compiler uses to print visible and trimmed paths.

Here’s the function that does it:

https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/print/pretty/trait.PrettyPrinter.html#method.try_print_visible_def_path

It seems like, to use this for something other than printing, rustdoc will need to look in the Visible Parent Map, instead of using the “true” parent, to compute the path for linking:

https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.visible_parent_map

[GuillaumeGomez]

I found the solution: def_path_str. Unless we want to rewrite the implementation in rustdoc directly (which I'm not a big fan of), I think it's better to simply parse the string.

[notriddle]

Unless we want to rewrite the implementation in rustdoc directly (which I'm not a big fan of), I think it's better to simply parse the string.

As long as you're sure it's only going to require splitting on ::, and will never return a complex, fully-qualified path such as <MyType as Display>::fmt

[GuillaumeGomez]

Such types don't have their own page generated yet, so we can worry about it later on. Also I forgot to update some tests so CI will fail. ^^'

[notriddle]

I don't think this function should ever be invoked with an associated item, but just to be on the safe side:

Suggested change

	once(crate_name)
	.chain(cx.tcx.def_path_str(did).split("::").map(|entry| Symbol::intern(entry)).skip(1))
	.collect()
	let path_str = cx.tcx.def_path_str(did);
	// This function should never be invoked on a trait method.
	assert!(!path_str.contains('<'));
	// This function should never be invoked on a closure or impl.
	assert!(!path_str.contains('{'));
	once(crate_name)
	.chain(path_str.split("::").map(|entry| Symbol::intern(entry)).skip(1))
	.collect()

[GuillaumeGomez]

I reverted this part until the extern re-exports are correctly handled as mentioned above.

[notriddle]

You mean def_path_str is not returning the path that would actually be used for accessing the item in the dependent crate?

[GuillaumeGomez]

It actually returns the path used to import the item. Which doesn't work in case like:

pub mod quux {
    extern crate issue_30109_1 as bar;
    use self::bar::Bar;

    pub trait Foo {}

    // @has issue_30109/quux/trait.Foo.html \
    //          '//a/@href' '../issue_30109_1/struct.Bar.html'
    impl Foo for Bar {}
}

In here, Bar path will include bar but also self (in the form of the current crate name) whereas it definitely shouldn't.

[notriddle]

I see. Ick.

[GuillaumeGomez]

Here's the PR and feature which should allow to fix this definitely at some point: #112853 (the PR doesn't fix it, just adds tests for the feature).

[GuillaumeGomez]

I updated the top-comment. Currently we still need redirection files until external re-exports are correctly "exported" by the compiler. Hopefully, it shouldn't take too long. :)

[GuillaumeGomez]

CI passed this time.

[notriddle]

@bors r+

[bors]

📌 Commit 3ad595a has been approved by notriddle

It is now in the queue for this repository.