Skip to content

Rustdoc ignores -W help #83883

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
jyn514 opened this issue Apr 5, 2021 · 4 comments · Fixed by #83895
Closed

Rustdoc ignores -W help #83883

jyn514 opened this issue Apr 5, 2021 · 4 comments · Fixed by #83895
Assignees
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@jyn514
Copy link
Member

jyn514 commented Apr 5, 2021

I tried this code: rustdoc -W help
I expected to see this happen: Rustdoc prints a list of all lints, the same way rustc does.
Instead, this happened: Rustdoc ignored the flag.

Meta

rustdoc --version: rustdoc 1.53.0-nightly (0b417ab 2021-04-03)

@jyn514 jyn514 added C-bug Category: This is a bug. A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Apr 5, 2021
@eggyal
Copy link
Contributor

eggyal commented Apr 5, 2021

-W help option is parsed into librustdoc::config::Options::describe_lints, but is then ignored:

/// Whether to ask rustc to describe the lints it knows. Practically speaking, this will not be
/// used, since we abort if we have no input file, but it's included for completeness.
crate describe_lints: bool,

It should be pretty straightforward to instead call rustc_driver::describe_lints when this flag is set.

@rustbot claim

@jyn514
Copy link
Member Author

jyn514 commented Apr 5, 2021

Make sure you call init_lints first, or it will be missing rustdoc's own lints.

@eggyal
Copy link
Contributor

eggyal commented Apr 5, 2021

Re adding a test for this... is there any way to have compiletest check only for whether some substring appears within stderr? Else every time a lint is added/removed, or its level modified, the test will need updating—which seems far too brittle to me?

@jyn514
Copy link
Member Author

jyn514 commented Apr 5, 2021

Else every time a lint is added/removed, or its level modified, the test will need updating—which seems far too brittle to me?

I mean, personally that seems ok to me as long as you can update it with --bless. But if you think it's a hassle you could use --error-pattern.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants