rustdoc: add --print option

[ShE3py]

Context: --print crate-root-lint-levels (#139180) is only available for rustc and clippy-driver, while it would make sense for it to also be available for rustdoc (à la #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 --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() and rustdoc() (or just test rustdoc as it delegates to rustc):

rust/tests/run-make/print-crate-root-lint-levels/rmake.rs

Lines 82 to 88 in 021fc25

	fn check(CrateRootLintLevels { args, contains }: CrateRootLintLevels) {
	let output = rustc()
	.input("lib.rs")
	.arg("-Zunstable-options")
	.print("crate-root-lint-levels")
	.args(args)
	.run();

@rustbot label +A-CLI +A-print-requests

[rustbot]

r? @notriddle

rustbot has assigned @notriddle.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Urgau]

I could indeed see the --print being useful in rustdoc, but I'm still a bit curious what your use-case.
Would you be able describe it?

[fmease]

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.

[fmease]

Moreover, --print=crate-name doesn't really make sense for *.md inputs I feel like?

[fmease]

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.

[ShE3py]

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).

[ShE3py]

I could indeed see the --print being useful in rustdoc, but I'm still a bit curious what your use-case. Would you be able describe it?

I'd like to diff the default lint-levels of two Rust versions in order to simplify updating the lints when I come back after a while (e.g. remove -W foo if foo was promoted to warn-by-default).

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[ShE3py]

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)