rustdoc: add --print option - #151618
Conversation
|
r? @notriddle rustbot has assigned @notriddle. Use |
This comment has been minimized.
This comment has been minimized.
|
I could indeed see the |
| return; | ||
| } | ||
|
|
||
| if rustc_driver::print_crate_info(&*compiler.codegen_backend, sess, true) |
There was a problem hiding this comment.
Note: IINM, this won't be run if the input file is *.md or if --test is passed. Not sure what the consequences of that are.
There was a problem hiding this comment.
Moreover, --print=crate-name doesn't really make sense for *.md inputs I feel like?
| } | ||
| }; | ||
|
|
||
| let prints = |
There was a problem hiding this comment.
I sense that there are certain rustc print requests which I don't think rustdoc can support.
E.g., I'm curious what will happen if you pass --print=link-args to rustdoc under your PR. Contrary to most other rustc print request that make rustc stop compilation early, link-args actually requires full analysis+codegen IINM … which rustdoc obv doesn't do. I guess it just doesn't print anything?
If so, that would be an example of a rustc print request that shouldn't be a legal rustdoc one.
There's also --print=native-static-libs that seems to require sth. similar.
There was a problem hiding this comment.
E.g., I'm curious what will happen if you pass --print=link-args to rustdoc under your PR. Contrary to most other rustc print request that make rustc stop compilation early, link-args actually requires full analysis+codegen IINM … which rustdoc obv doesn't do. I guess it just doesn't print anything?
Yup, print_crate_info is a no-op for them as it's codegen_ssa that print them, and since the codegen isn't called, they don't print anything.
I'll filter the prints depending on if they make sense depending on the file type (.rs / .md / both) and action (doc / doctest / any).
I'd like to @rustbot author |
|
Reminder, once the PR becomes ready for a review, use |
This comment has been minimized.
This comment has been minimized.
| (option_env!("CFG_COMPILER_HOST_TRIPLE")).expect("CFG_COMPILER_HOST_TRIPLE") | ||
| env!("CFG_COMPILER_HOST_TRIPLE") |
There was a problem hiding this comment.
That was changed from env! to option_env! in the first commit of #13724, but not sure why this change was made or if it's still relevant as CI is green.
(Was looking looking for a #[expect] reason as removing the extra parentheses triggers deny-by-default clippy::option_env_unwrap)
This comment has been minimized.
This comment has been minimized.
|
@ShE3py still interested in driving this PR forward? |
|
Yup, prolly next month when I have time. |
|
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. |
| // -W help | ||
| if sess.opts.describe_lints { | ||
| rustc_driver::describe_lints(sess, registered_lints); | ||
| return Ok(None); | ||
| } |
There was a problem hiding this comment.
Fixes -W help when running doctests:
$ rustdoc +nightly -Whelp --test /dev/null
error: couldn't find file ``
There was a problem hiding this comment.
Copied from tests/run-make/print-crate-root-lint-levels/, replaced unexpected_cfgs with rustdoc::private_doc_tests.
|
I have grouped the I can somewhat far-fetch someone using For Markdown files and doctests, @rustbot review |
|
@bors delegate+ The fix commits need squashed. But this looks okay, otherwise. r=me after squashing. |
|
✌️ @ShE3py, you can now approve this pull request! If @notriddle told you to " |
|
I've also added tests for |
|
@bors r+ |
rustdoc: add `--print` option Context: `--print crate-root-lint-levels` (rust-lang#139180) is only available for `rustc` and `clippy-driver`, while it would make sense for it to also be available for `rustdoc` (à la rust-lang#83895.) Not too sure about the stability of `rustdoc --print=any` or if this needs a MCP; strictly speaking, only `rustdoc +nightly -Z unstable-options --print=crate-root-lint-levels` would be required (and the `rustdoc --print` would be stabilized together with `crate-root-lint-levels`), but I guess that makes sense to have all the `--print`s for consistency. For regression tests, not sure if ui or run-make is preferable, as run-make would need some sort of trait to avoid duplicating code between `rustc()` and `rustdoc()` (or just test `rustdoc` as it delegates to `rustc`): https://github.com/rust-lang/rust/blob/021fc25b7a48f6051bee1e1f06c7a277e4de1cc9/tests/run-make/print-crate-root-lint-levels/rmake.rs#L82-L88 @rustbot label +A-CLI +A-print-requests
|
💔 I suspect this PR failed tests as part of a rollup After fixing the problem, consider running a try job for the failed job before re-approving. Link to failure: #162081 (comment) |
|
This pull request was unapproved. This PR was contained in a rollup (#162081), which was unapproved. |
|
@bors try jobs=test-various,x86_64-msvc-* |
This comment has been minimized.
This comment has been minimized.
rustdoc: add `--print` option try-job: test-various try-job: x86_64-msvc-*
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test for 8facfe3 failed: CI. Failed job:
|
View all comments
Context:
--print crate-root-lint-levels(#139180) is only available forrustcandclippy-driver, while it would make sense for it to also be available forrustdoc(à la #83895.)Not too sure about the stability of
rustdoc --print=anyor if this needs a MCP; strictly speaking, onlyrustdoc +nightly -Z unstable-options --print=crate-root-lint-levelswould be required (and therustdoc --printwould be stabilized together withcrate-root-lint-levels), but I guess that makes sense to have all the--prints for consistency.For regression tests, not sure if ui or run-make is preferable, as run-make would need some sort of trait to avoid duplicating code between
rustc()andrustdoc()(or just testrustdocas it delegates torustc):rust/tests/run-make/print-crate-root-lint-levels/rmake.rs
Lines 82 to 88 in 021fc25
@rustbot label +A-CLI +A-print-requests