Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Cleanup rustdoc lint listing #80455

Conversation

GuillaumeGomez
Copy link
Member

Fixes #78786.

Explanations: we need a compiler instance in order to be able to get a LintStore which allows us to get access to the "rustdoc" lint group. It has the advantage that we don't require to keep this list up-to-date by manually anymore. Maybe it might be worth a perf check? Didn't see an impact when running locally but maybe there might be one?

r? @jyn514

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 28, 2020
@GuillaumeGomez GuillaumeGomez force-pushed the cleanup-rustdoc-lint-listing branch from 4ce91b5 to c6ef320 Compare December 28, 2020 21:24
@rust-lang rust-lang deleted a comment from rust-highfive Dec 28, 2020
@GuillaumeGomez GuillaumeGomez added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Dec 28, 2020
Copy link
Member

@jyn514 jyn514 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a hack, but I think it's better than the existing mess. I don't think you need a full perf run, but if you can add tcx.sess.time("init lints") to see how long get_rustdoc_lints takes to execute that would be nice (I expect not very long).

@@ -321,6 +321,7 @@ fn register_builtins(store: &mut LintStore, no_interleave_lints: bool) {
INVALID_CODEBLOCK_ATTRIBUTES,
MISSING_DOC_CODE_EXAMPLES,
PRIVATE_DOC_TESTS,
MISSING_CRATE_LEVEL_DOCS,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be mixed in with the cleanup; it's the same sort of change as #77364, which I'm still not convinced is the right change.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's only emitted by rustdoc, so the context is a bit different there. This whole PR wouldn't be possible without this change because otherwise I'll need to still handle this lint differently than the others. However, because it was a bit out of the scope of this PR, I have put this change in a commit on its own (it's the first commit, you can check ;) ).

Comment on lines 301 to 302
// In addition to those specific lints, we also need to allow those given through
// command line, otherwise they'll get ignored and we don't want that.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// In addition to those specific lints, we also need to allow those given through
// command line, otherwise they'll get ignored and we don't want that.
// Rustdoc silences all lints by default, only warning on lints in the `rustdoc` group.
// These lints aren't in the lint group, but we want to warn on them anyway.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, if I understand correctly, rustdoc will no longer warn even if you add -W non_upper_case_globals or something like that, is that correct? I'm ok with that change personally, but it needs an FCP IMO.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It currently doesn't. I tried with this code:

pub static foo: u32 = 0;

fn main() {}

Then I ran:

$ rustdoc foo.rs -W non_upper_case_globals
$ rustc foo.rs -W non_upper_case_globals
warning: static variable `foo` should have an upper case name
 --> foo.rs:1:12
  |
1 | pub static foo: u32 = 0;
  |            ^^^ help: convert the identifier to upper case (notice the capitalization): `FOO`
  |
  = note: requested on the command line with `-W non-upper-case-globals`

warning: 1 warning emitted

So no changes there as far as I can see.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for info, here are the versions:

$ rustdoc --version
rustdoc 1.51.0-nightly (2987785df 2020-12-28)
$ rustc --version
rustc 1.51.0-nightly (2987785df 2020-12-28)

src/librustdoc/core.rs Show resolved Hide resolved
maybe_sysroot,
search_paths: libs,
crate_types,
lint_opts: if !display_warnings { lint_opts } else { vec![] },
lint_opts: vec![],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a change in behavior (the same one from #73314). I think it's a good change, but it shouldn't be mixed in with a cleanup.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it's not. Look just below: I set lint_opts after using the get_rustdoc_lints function. So it's the same but applied in two steps. I need this first one to do the least amount of things as possible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be exact, it's done here:

if !display_warnings {
    sessopts.lint_opts = lint_opts;
}

Comment on lines +386 to +388
// FIXME: why is this necessary?
if lint.name == broken_intra_doc_links || lint.name == invalid_codeblock_attributes_name {
None
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you remove this, does it still warn on those lints?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't want to update it in this PR to avoid mixing too many things together. We can take a look when this is merged if you want.

@jyn514 jyn514 added the A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. label Dec 30, 2020
…group instead of handling this list "by hand"
@GuillaumeGomez
Copy link
Member Author

This is a hack, but I think it's better than the existing mess. I don't think you need a full perf run, but if you can add tcx.sess.time("init lints") to see how long get_rustdoc_lints takes to execute that would be nice (I expect not very long).

Only problem with that is that I don't have a tcx nor a Session at this point. 😞

@GuillaumeGomez GuillaumeGomez force-pushed the cleanup-rustdoc-lint-listing branch from c6ef320 to 32c3cc0 Compare December 30, 2020 13:44
@GuillaumeGomez
Copy link
Member Author

So in the end, I just applied the comment update you suggested. 😆

@GuillaumeGomez
Copy link
Member Author

Since there is now #80527, this PR is not necessary anymore. Closing it!

@GuillaumeGomez GuillaumeGomez deleted the cleanup-rustdoc-lint-listing branch January 4, 2021 14:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Rustdoc should never silence lints from the rustdoc lint group
3 participants