feat: rebuild(-ish) rustdoc json for different version of same crates#16773
feat: rebuild(-ish) rustdoc json for different version of same crates#16773motorailgun wants to merge 2 commits intorust-lang:masterfrom
Conversation
|
r? @epage rustbot has assigned @epage. Use Why was this reviewer chosen?The reviewer was selected based on:
|
a1ef71b to
04024f4
Compare
be69519 to
2f32d53
Compare
|
Updated to use new directory layout. |
This comment has been minimized.
This comment has been minimized.
2f32d53 to
184bf76
Compare
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
939c055 to
79399ac
Compare
|
Note: updated PR message reflecting changes. |
79399ac to
be0b993
Compare
| } | ||
|
|
||
| let crate_dir = doc_dir.join(&crate_name); | ||
| let crate_dir = if is_json_output { |
There was a problem hiding this comment.
We don't need to clean up doc.json file for the new layout, as they are isolated by units.
That said, I do want to know how this would affect cargo clean --doc. We should at least track it in the tracking issue
There was a problem hiding this comment.
From my quick observation, doc.json file will escape normal cargo clean --doc operation? Will dig into tomorrow.
cargo/src/cargo/ops/cargo_clean.rs
Lines 88 to 100 in f4f977f
There was a problem hiding this comment.
Tracking issue btw: #13283
Though I feel like we probably don't need to deal with cargo clean --doc. So the behavior doesn't need to be "cleaning anything related to artifacts."
--doc
This option will cause cargo clean to remove only the doc directory in the target directory.
That makes me wonder -Zrustdoc-mergeable-info also doesn't need to support cargo clean.
@ranger-ross any thoughts?
There was a problem hiding this comment.
I meant, we may leave it for future. No need to worry about it now
e727c71 to
225d510
Compare
86007ed to
ca752fa
Compare
ca752fa to
9e895e1
Compare
| debug!("removing pre-existing doc directory {:?}", crate_dir); | ||
| paths::remove_dir_all(crate_dir)?; | ||
| } | ||
| if !is_json_output { |
There was a problem hiding this comment.
rustdoc --output-format currently only accepts one format and each option is mutually exclusive, so this check should be fine for now.
If it ever changes to accepts muliple, we'll need to update this (and this place is unlikely the only place need an update).
| build_runner: &BuildRunner<'_, '_>, | ||
| rustdoc: &mut ProcessBuilder, | ||
| ) -> CargoResult<()> { | ||
| let gctx = build_runner.bcx.gctx; |
There was a problem hiding this comment.
nit: This is a better to be a refactor commit.
| assert!(!dep_json.contains("dep_v1_fn")); | ||
| assert!(dep_json.contains("dep_v2_fn")); | ||
| assert!(dep_json.contains("dep_v1_fn")); | ||
| assert!(!dep_json.contains("dep_v2_fn")); |
There was a problem hiding this comment.
Nice test that makes cargo replaces outdated uplifted content!
|
BTW, if follows conventional commit message stricter, the first commit should be Anyway, thanks! |
|
Oh, is that failing test just flaky? If so I'd love to take some time to amend the commits (messages and histories). |
Yeah definitely flaky. Feel free to amend the commits if you'd like to. I will merge this on Friday anyway before the next Cargo submodule sync in rust-lang/rust (which is probably tomorrow within 24hrs) |
View all comments
Fix #16291.
What does this PR try to resolve?
As discussed in the linked issue,
cargo rustdoc --output-format=jsondoesn't rebuild for same crate name but with different versions. This is because current cargo implementation around rustdoc only specifies output paths/names by only its crate names, but not with version(hash) info.This PR forces new layout for json output, and uplift the file into backward-compatible place.
How to test and review this PR?
--output-format=json? (and stop uplifting)