Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation links are difficult #36417

Closed
matthew-piziak opened this issue Sep 12, 2016 · 4 comments
Closed

Documentation links are difficult #36417

matthew-piziak opened this issue Sep 12, 2016 · 4 comments
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools C-feature-request Category: A feature request, i.e: not implemented / a PR. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue.

Comments

@matthew-piziak
Copy link
Contributor

matthew-piziak commented Sep 12, 2016

Workflow criteria

An efficient workflow must satisfy one of two criteria:

  • Determinism: the change of success per attempt is high.
  • Iteration Speed: the frequency of attempts is high.

Composing links in documentation does not currently satisfy either of these criteria. The rules for linking are mysterious enough that a contributor cannot be confident that they will work without running make docs.

Examples of pain

#32130: a struct can be viewed from two locations, at varying depths of links; sometimes links to methods refer to the wrong modules.
#35880: doc entities are replicated between std and core.
#35759: directory links are confusing; anchors are case sensitive and do not match rendered content.
#rust-docs logs: Linkchecker is not always reliable (or potentially has usability problems).
#rust-docs logs: If a URL is present in both item description and short description, in the second case it won't work.

Potential resolutions

My hope is that this problem is procedural. It's entirely likely that I'm just wrong! If that's the case, then this issue can be resolved with documentation that either: 1) specifies a fast way to programmatically check docs locally, or 2) specifies a deterministic set of rules (a checklist) that allows a contributor to verify that their links will be successful without compiling them.

If I'm not wrong, then the problem becomes more difficult, which is why I created this issue. I appreciate any insight from more experienced members of the community.

@ollie27
Copy link
Member

ollie27 commented Sep 12, 2016

#rust-docs logs: Linkchecker is not always reliable (or potentially has usability problems).

There seems to have been some confusion here. linkchecker needs to be run on the doc output directory, not the source code directory. So assuming you're using the Makefiles the full instructions would look something like:

$ ./configure
$ make docs
$ cd src/tools/linkchecker
$ cargo run --release -- ../../../doc

@durka
Copy link
Contributor

durka commented Sep 12, 2016

  1. Make up a real syntax for linking to Rust items (requires a Markdown extension or pre/postprocessor). See RFC: Relative link syntax for rustdoc rfcs#1661 (postponed)

@steveklabnik steveklabnik removed the A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools label Mar 10, 2017
@steveklabnik steveklabnik added A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools and removed A-docs labels Mar 23, 2017
@steveklabnik
Copy link
Member

rust-lang/rfcs#1946 should help with this!

@frewsxcv frewsxcv added the T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. label Jun 8, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 26, 2017
@steveklabnik
Copy link
Member

RFC was merged, closing as a duplicate of #43466

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools C-feature-request Category: A feature request, i.e: not implemented / a PR. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants