Incorrect relative links on FnMut trait

[notriddle]

rust-analyzer version: rust-analyzer version: 0.3.2037-standalone e9afba57a 2024-07-14

rustc version: rustc 1.76.0 (07dca489a 2024-02-04)

editor or extension: VSCodium Version: 1.88.1 Release: 24104 Commit: 0d01a72525276e5e3771fe5851b9c83de0de1e2b Date: 2024-04-13T01:43:30.924Z (3 mos ago) Electron: 28.2.8 ElectronBuildId: undefined Chromium: 120.0.6099.291 Node.js: 18.18.2 V8: 12.0.267.19-electron.0 OS: Darwin arm64 23.5.0

code snippet to reproduce: To reproduce the problem, mouse over FnMut and click the link "See the chapter on closures in The Rust Programming Language for some more information on this topic."

fn my_fn() -> impl FnMut() -> () {
    || {}
}

See also: https://github.com/rust-lang/rust/pull/127790

[shigma]

I think it is the hoisting behavior that lead to this issue. Rust doc will generate doc at

https://doc.rust-lang.org/nightly/core/ops/trait.FnMut.html

and not

https://doc.rust-lang.org/nightly/core/ops/function/trait.FnMut.html (this link will redirect to above one)

This introduces inconsistency between source codes and docs.

Is it possible to fix it by changing the rustdoc behavior, for example, redirect the former link to the latter one?

[notriddle]

I’d rather base the generated docs on the actual, public API. Not on private implementation details.

error[E0603]: module `function` is private
   --> src/lib.rs:1:16
    |
1   | use core::ops::function::FnMut;
    |                ^^^^^^^^ private module
    |

[Veykril]

What are the rules here? Does rustdoc uplift items defined within private modules up to their public re-export (what if there are multiple)?

[shigma]

I’d rather base the generated docs on the actual, public API.

You are right.

How about write comments based on the real path, and then generate docs with all the paths transformed to public ones? In that case, links from both docs and IDE will work.

[notriddle]

https://doc.rust-lang.org/nightly/rustdoc/write-documentation/re-exports.html