-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Cleanup rustdoc lint listing #80455
Conversation
4ce91b5
to
c6ef320
Compare
There was a problem hiding this 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, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 ;) ).
src/librustdoc/core.rs
Outdated
// 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
maybe_sysroot, | ||
search_paths: libs, | ||
crate_types, | ||
lint_opts: if !display_warnings { lint_opts } else { vec![] }, | ||
lint_opts: vec![], |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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;
}
// FIXME: why is this necessary? | ||
if lint.name == broken_intra_doc_links || lint.name == invalid_codeblock_attributes_name { | ||
None |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
…group instead of handling this list "by hand"
Only problem with that is that I don't have a |
c6ef320
to
32c3cc0
Compare
So in the end, I just applied the comment update you suggested. 😆 |
Since there is now #80527, this PR is not necessary anymore. Closing it! |
Fixes #78786.
Explanations: we need a
compiler
instance in order to be able to get aLintStore
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