Description
Compiler lints can be printed with rustc -W help
, with no filename arguments given. Unfortunately this doesn't work the same way for rustdoc
:
❯ rustdoc -W help
error: missing file operand
If I pass it an arbitrary file, it will print any errors produced by parsing the file as rust. This includes errors from using async
without passing --edition 2018
. This part is actually the same as rustc -W help
, in that passing arbitrary files to that produces the same behavior.
If I pass it a file that parses cleanly (either 2015 rust, or 2018 rust with --edition 2018
specified) then and only then will rustdoc -W help
actually print the lint groups. In this way it behaves similarly to rustc -W help $filename
in that rustc
will also print the lint groups when passed a filename that parses cleanly. The difference is that rustc -W help
doesn't require a filename at all.
The simplest workaround here is to type rustdoc -W help /dev/null
as the empty /dev/null
file does not trigger any parse errors.
Potential root cause
It's possible that the root cause here is that calling rustdoc
with no args produces the same error:
❯ rustdoc
error: missing file operand
Compare this with rustc
, which prints the help:
❯ rustc
Usage: rustc [OPTIONS] INPUT
Options:
-h, --help Display this message
--cfg SPEC Configure the compilation environment
-L [KIND=]PATH Add a directory to the library search path. The
︙
This suggests that rustdoc
is checking for filename arguments and erroring out early on, whereas rustc
skips that check and then later interprets "no filename args" as "fallback to help".
Meta
❯ rustdoc --version --verbose
rustdoc 1.54.0 (a178d0322 2021-07-26)
binary: rustdoc
commit-hash: a178d0322ce20e33eac124758e837cbd80a6f633
commit-date: 2021-07-26
host: x86_64-apple-darwin
release: 1.54.0
LLVM version: 12.0.1
❯ rustdoc +nightly --version --verbose
rustdoc 1.57.0-nightly (fdf65053e 2021-09-07)
binary: rustdoc
commit-hash: fdf65053e99e8966f9bd83b5a8491326cb33d638
commit-date: 2021-09-07
host: x86_64-apple-darwin
release: 1.57.0-nightly
LLVM version: 13.0.0