rustdoc-json: add rlib path to ExternalCrate to enable robust crate resolution [WIPWIPWIP] #149043
+15
−5
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Historically, it's not been possible to robustly resolve a cross-crate item in rustdoc-json. If you had a
Idthat wasn't inCrate::index(because it was defined in a different crate), you could only look it up itCrate::paths. But there, you don't get the full information, only anItemSummary. This tells you thepathand thecrate_id.But knowing the
crate_idisn't enough to be able to build/find the rustdoc-json output with this item. It's only use is to get aExternalCrate(viaCrate::external_crates). But that only tells you thename(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-idproposal (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:
Footnotes
https://github.com/rust-lang/compiler-team/issues/635#issue-1714254865 § Problem ↩
https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Identifying.20external.20crates.20in.20Rustdoc.20JSON/with/352701211 ↩
https://github.com/obi1kenobi/cargo-semver-checks/issues/638 ↩