Skip to content

Conversation

@aDotInTheVoid
Copy link
Member

Historically, it's not been possible to robustly resolve a cross-crate item in rustdoc-json. If you had a Id that wasn't in Crate::index (because it was defined in a different crate), you could only look it up it Crate::paths. But there, you don't get the full information, only an ItemSummary. This tells you the path and the crate_id.

But knowing the crate_id isn't enough to be able to build/find the rustdoc-json output with this item. It's only use is to get a ExternalCrate (via Crate::external_crates). But that only tells you the name (as a string). This isn't enough to uniquely identify a crate, as there could be multiple versions/features 1 2.

This was originally proposed to be solved via @LukeMathWalker's --orchestrator-id proposal (rust-lang/compiler-team#635). But that requires invasive changes to cargo/rustc. This PR instead implements @Urgau's proposal to re-use the path to a crate's rmeta/rlib as a unique identifer. Callers can use that to determine which package it corresponds to in the language of the build-system above rustc. E.g. for cargo, cargo rustdoc --message-format=json --output-format=json -Zunstable-options).

(Once you've found the right external crate's rustdoc-json output, you still need to resolve the path->id in that crate. But that's """just""" a matter of walking the module tree. We should probably still make that nicer (by, for example, allowing sharing Ids between rustdoc-json document), but that's a future concern)

For some notes from RustWeek 2025, where this was designed, see https://hackmd.io/0jkdguobTnW7nXoGKAxfEQ

CC @obi1kenobi (who wants this for cargo-semver-checks 3), @epage (who's conversations on what and wasn't possible with cargo informed taking this approach to solve this problem)

r? @GuillaumeGomez

TODO:

  • Docs
  • Tests

Footnotes

  1. https://github.com/rust-lang/compiler-team/issues/635#issue-1714254865 § Problem

  2. https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Identifying.20external.20crates.20in.20Rustdoc.20JSON/with/352701211

  3. https://github.com/obi1kenobi/cargo-semver-checks/issues/638

@rustbot
Copy link
Collaborator

rustbot commented Nov 17, 2025

rustdoc-json-types is a public (although nightly-only) API. If possible, consider changing src/librustdoc/json/conversions.rs; otherwise, make sure you bump the FORMAT_VERSION constant.

cc @CraftSpider, @aDotInTheVoid, @Enselic, @obi1kenobi

@rustbot rustbot added the A-rustdoc-json Area: Rustdoc JSON backend label Nov 17, 2025
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Nov 17, 2025
@rustbot
Copy link
Collaborator

rustbot commented Nov 17, 2025

⚠️ Warning ⚠️

  • There are username mentions (such as @user) in the commit messages of the following commits.
    Please remove the mentions to avoid spamming these users.

@aDotInTheVoid aDotInTheVoid marked this pull request as draft November 17, 2025 23:48
@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 17, 2025
…esolution

Historically, it's not been possible to robustly resolve a cross-crate
item in rustdoc-json. If you had a `Id` that wasn't in `Crate::index`
(because it was defined in a different crate), you could only look it up
it `Crate::paths`. But there, you don't get the full information, only
an `ItemSummary`. This tells you the `path` and the `crate_id`.

But knowing the `crate_id` isn't enough to be able to build/find the
rustdoc-json output with this item. It's only use is to get a
`ExternalCrate` (via `Crate::external_crates`). But that only tells you
the `name` (as a string). This isn't enough to uniquely identify a
crate, as there could be multiple versions/features [1] [2].

This was originally proposed to be solved via LukeMathWalker's
`--orchestrator-id` proposal
(https://www.github.com/rust-lang/compiler-team/issues/635). But that
requires invasive changes to cargo/rustc. This PR instead implements
Urgau's proposal to re-use the path to a crate's rmeta/rlib as a unique
identifer. Callers can use that to determine which package it
corresponds to in the language of the build-system above rustc. E.g. for
cargo, `cargo rustdoc --message-format=json --output-format=json
-Zunstable-options`).

(Once you've found the right external crate's rustdoc-json output, you
still need to resolve the path->id in that crate. But that's """just"""
a matter of walking the module tree. We should probably still make that
nicer (by, for example, allowing sharing `Id`s between rustdoc-json
document), but that's a future concern)

For some notes from RustWeek 2025, where this was designed, see
https://hackmd.io/0jkdguobTnW7nXoGKAxfEQ

[1]: https://www.github.com/rust-lang/compiler-team/issues/635#issue-1714254865 § Problem
[2]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Identifying.20external.20crates.20in.20Rustdoc.20JSON/with/352701211
@rust-cloud-vms rust-cloud-vms bot force-pushed the is-this-real-is-this-out-of-spite-does-it-matter branch from c7f4e67 to 2e1b954 Compare November 17, 2025 23:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-rustdoc-json Area: Rustdoc JSON backend S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants