Stabilize rustdoc --merge --parts-out-dir, and --include-parts-dir options#152902
Stabilize rustdoc --merge --parts-out-dir, and --include-parts-dir options#152902GuillaumeGomez wants to merge 1 commit into
--merge --parts-out-dir, and --include-parts-dir options#152902Conversation
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
While mergeable info arguments standalone is great, it won't be that useful until we have --emit stabllilized I guess?
| ```console | ||
| $ rustdoc +nightly crate1.rs --merge=none --parts-out-dir=crate1.d -Zunstable-options | ||
| $ cat doc/search.index/crateNames/* | ||
| cat: 'doc/search.index/crateNames/*': No such file or directory | ||
| $ rustdoc +nightly crate2.rs --merge=finalize --include-parts-dir=crate1.d -Zunstable-options | ||
| $ cat doc/search.index/crateNames/* | ||
| rd_("fcrate1fcrate2") | ||
| ``` |
There was a problem hiding this comment.
Might be helpful to adjust the example to have another dependency crate too so we can show passing --include-parts-dir multiple times at once.
|
@rfcbot fcp merge |
|
Error encounted: |
|
@rfcbot concern wait for stabilization of --emit? |
|
@rfcbot fcp merge rustdoc |
|
Team member @camelid has proposed to merge this. The next step is review by the rest of the tagged team members:
Concerns:
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
|
@rfcbot concern wait for stabilization of --emit? |
|
BTW, have we heard back from the Bazelz Buck2, and other build system communities that this is useful and comprehensive for them to integrate? |
Here's the latest I know of from the Bazel side, there are plans but no proof of concept yet: bazelbuild/rules_rust#1837 (comment) |
|
I'll also stabilize |
79f4541 to
facb206
Compare
|
This PR was rebased onto a different main 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. |
What do you mean by this? #146220 is perfectly fine and can be merged before this PR once all 4 of its blocking concerns are resolved and its FCP has concluded. |
|
Let's put on that on tired monday... Removing my second commit then. I'll link to the other PR in my first message. |
facb206 to
f447fab
Compare
This comment has been minimized.
This comment has been minimized.
f447fab to
8f3b559
Compare
|
And fixed the CI. |
| ## `--merge`, `--parts-out-dir` and `--include-parts-dir`: control how rustdoc handles files that combine data from multiple crates | ||
|
|
||
| By default, they act like `--merge=shared` is set, and `--parts-out-dir` and `--include-parts-dir` | ||
| are turned off. The `--merge=shared` mode causes rustdoc to load the existing data in the out-dir, |
There was a problem hiding this comment.
To be clear, we aren’t committing to a particular layout. Just that rustdoc handles them automatically.
We currently go to some effort to “decompile” the output JSON to read it back in, but we don’t have to do it that way. We could drop a .cci folder into the out-dir and read the new-style JSON from there.
Fixes #130676.
Needs for #146220 to be merged first as these options would be less useful if
--emitis not stable as well.As discussed in the last rustdoc team meeting, the options can be stabilized as is.
cc @notriddle
r? @camelid