Skip to content

Use semver compatible links to dependencies #1055

Open
@Nemo157

Description

@Nemo157

Currently when we build documentation we pass a flag like --extern-html-root-url foobar=https://docs.rs/foobar/1.0.0 for each dependency with the exact version of the dependency used. This means if the dependency releases a new version compatible with the version constraint, all the links to it from the dependent crate will still go to the old version.

To avoid this we could pass semver-constraint urls like --extern-html-root-url foobar=https://docs.rs/foobar/^1.0.0 (based on the actual constraint specified), then links will automatically go to the latest compatible version of the docs.


The biggest blocker to doing so is getting guarantees from Rustdoc that intra-doc-links generated for one version of a crate will still be valid in all semver-compatible later versions of the crate. A couple of issues currently cause this to not be true:

  1. The exact kind of a type is part of the url, so while e.g. changing a struct to an enum is a non-breaking change to code, it will result in a link to the item becoming a 404 (Use name.namespace.html as the canonical URL, not kind.name.html rust#55160)
  2. Re-exports don't exist in the file tree, as an example consider these two versions of a crate:
// Version 1.0.0
pub struct Foo;
// Version 1.0.1 - A semver compatible change to move the canonical location and leave a re-export behind
pub mod foo { pub struct Foo; }
pub use foo::Foo;

Looking at the filetree of the built docs we can see that a link to the old canonical location of foo/struct.Foo.html will be a 404 in the new version:

target/doc/foo
├── all.html
├── index.html
├── sidebar-items.js
└── struct.Foo.html

target/doc/foo
├── all.html
├── foo
│   ├── index.html
│   ├── sidebar-items.js
│   └── struct.Foo.html
├── index.html
└── sidebar-items.js

(There may be more issues, these are just what was linked to me by @jyn514 and the first thought I had of what might go wrong. The first step of actually working on this if it's worth it would be identifying all the potential issues and working out whether it's possible/worthwhile trying to get this guarantee out of Rustdoc).

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-buildsArea: Building the documentation for a crateC-enhancementCategory: This is a new featureS-blockedStatus: marked as blocked ❌ on something else such as an RFC or other implementation work.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions