-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Implement tool_lints #2977
Implement tool_lints #2977
Conversation
#[macro_use] | ||
extern crate serde_derive; | ||
|
||
/// Test that we do not lint for unused underscores in a `MacroAttribute` | ||
/// expansion | ||
#[deny(used_underscore_binding)] | ||
#[deny(clippy::used_underscore_binding)] | ||
#[derive(Deserialize)] |
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.
FIXMEFIXED: I get a weird error here:
error: proc-macro derive panicked
--> tests/run-pass/used_underscore_binding_macro.rs:7:10
|
7 | #[derive(Deserialize)]
| ^^^^^^^^^^^
|
= help: message: called `Result::unwrap()` on an `Err` value: "failed to parse derive input: \"/// Test that we do not lint for unused underscores in a `MacroAttribute`\\n/// expansion\\n#[deny(clippy::used_underscore_binding)]\\nstruct MacroAttributesTest {\\n _foo: u32,\\n}\""
That's because somehow syn
fails to parse the new tool_lints
...
See serde and syn
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.
we just need to update our dependency version requirement to the most recent one, then it'll work
@@ -2,7 +2,7 @@ | |||
//! floating-point literal expressions. | |||
|
|||
use rustc::lint::*; | |||
use rustc::{declare_lint, lint_array}; | |||
use rustc::{declare_tool_lint, lint_array}; |
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.
Why do we even need this imported here? Shouldn't declare_clippy_lint
be enough? Maybe we need to import it in the expansion of declare_clippy_lint
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.
Because we use the declare_clippy_lint!
which expands to ...declare_(tool_)lint!...
.
Maybe we need to import it in the expansion of declare_clippy_lint
That would probably be cleaner.
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.
Or not: If we use declare_clippy_lint
multiple times in one file we would get multiple use rustc::declare_tool_lint
. And that happens pretty often.
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.
can we just call rustc::declare_tool_lint!
instead of importing it?
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.
That should work. I'll try this.
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 we use rustc::declare_tool_lint!
in the macro_rule, we have to import use rustc
in each file, or else:
error[E0433]: failed to resolve. Use of undeclared type or module `rustc`
--> clippy_lints/src/lib.rs:24:9
|
24 | rustc::declare_tool_lint! { pub clippy::$name, Warn, $description, report_in_external_macro: true }
| ^^^^^ Use of undeclared type or module `rustc`
|
::: clippy_lints/src/bit_mask.rs:87:1
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.
:( ok, lets leave it as is then and punt to the future
Make the tool_lints actually usable cc rust-lang#44690 Necessary for rust-lang/rust-clippy#2955 and rust-lang/rust-clippy#2977 This PR makes it possible for lint tools (at the moment only for Clippy) to implement the `tool_lints`, like it was documented in rust-lang#52018. Because the `declare_lint` macro is pretty cluttered right now, there was not really a good way to add the `tool_name` as an additional argument of the macro. That's why I chose to introduce the new `declare_tool_lint` macro. The switch from `&str` to `String` in the `lint_groups` `FxHashMap` is because I got weird error messages in the `check_lint_name` method. And the `by_name` field of the `LintStore` also uses `String`. ### What comes with this PR: If this PR lands and Clippy switches to the `tool_lints`, the currently used methods ```rust #[cfg_attr(feature = "cargo-clippy", allow(clippy_lint))] #[allow(unknown_lints, clippy_lint)] ``` to `allow`/`warn`/`deny`/`forbid` Clippy lints, won't have any effects anymore, but also won't produce a warning. That is because the name of `clippy_lint` will then be `clippy::clippy_lint`. (Maybe we can add a clippy lint to search for `cfg_attr` appearances with the `cargo-clippy` feature?) r? @oli-obk
Does rustc allow you to use the old way of specifying these? I feel like we should have a week or two where rustc will match both |
Make the tool_lints actually usable cc rust-lang#44690 Necessary for rust-lang/rust-clippy#2955 and rust-lang/rust-clippy#2977 This PR makes it possible for lint tools (at the moment only for Clippy) to implement the `tool_lints`, like it was documented in rust-lang#52018. Because the `declare_lint` macro is pretty cluttered right now, there was not really a good way to add the `tool_name` as an additional argument of the macro. That's why I chose to introduce the new `declare_tool_lint` macro. The switch from `&str` to `String` in the `lint_groups` `FxHashMap` is because I got weird error messages in the `check_lint_name` method. And the `by_name` field of the `LintStore` also uses `String`. ### What comes with this PR: If this PR lands and Clippy switches to the `tool_lints`, the currently used methods ```rust #[cfg_attr(feature = "cargo-clippy", allow(clippy_lint))] #[allow(unknown_lints, clippy_lint)] ``` to `allow`/`warn`/`deny`/`forbid` Clippy lints, won't have any effects anymore, but also won't produce a warning. That is because the name of `clippy_lint` will then be `clippy::clippy_lint`. (Maybe we can add a clippy lint to search for `cfg_attr` appearances with the `cargo-clippy` feature?) r? @oli-obk
You can still use the I could have added a double check for My solution to this would be to write a lint for occurrences of We also need a lint for ...I should list this in #2955 |
Whoops my update script for the ui-tests slipped a little bit there. I'll reduce the number of lines changed a bit 😄 |
@flip1995 I meant that we can introduce such a warning into the rustc codebase itself, yeah? "If you use a lint that shares a name with a tool lint, here's a warning" |
for tool lint groups we can temporarily make the registration API ask for a deprecated fallback name We're the only consumers of this API, we can make changes like this 😄 |
I think I finished the ui-tests update. I looked through every |
Yes, we could lint in the rustc codebase for lints that are from tools aka Clippy. But this could only detect unscoped lints from Clippy if we compile the code with Clippy in the first place. In that case also Clippy can lint for usage of the unscoped lint names. (I'm sorry, if I'm missing the point of doing this in the compiler. Doing the ui-tests update was pretty
That makes sense to me. |
Yes, this is only if you're running with clippy.
Doing this in the compiler lets us have the lint allow still work. Otherwise the clippy user will get the deprecation warnings, as well as tons of unknown lint warnings and tons of silenced clippy warnings that get unsilenced. |
Ahh, I got it now! Thanks for the clarification! |
Travis should be green with the next nightly now. Do not merge this until the backwards compatibility is implemented in rustc. |
@flip1995 looks like some conflicts appeared |
Yeah, I currently working on the backwards compatibility of the tool_lints. After that I'll have to make adjustments here anyway. Also it will need a rebase. But I want to do this all at once. |
ping @flip1995 any update on the backwards compat? |
I will open a PR in rust-lang/rust by the end of this week |
It's almost finished, just need to prettify it a little. Sorry for the delay. |
a3aab0b
to
cbd178b
Compare
846fb4b
to
b4d31f4
Compare
4f1e3f4
to
daa4f0a
Compare
Rebased and pushed, and pinned daa4f0a to the tool-lints branch on this repo. When rust-lang/rust#53762 lands, please ensure that that commit gets into clippy master via git merge (NOT rebase) |
Backwards compatibility for tool/clippy lints cc #44690 cc rust-lang/rust-clippy#2977 (comment) This is the next step towards `tool_lints`. This makes Clippy lints still work without scoping, but will warn and suggest the new scoped name. This warning will only appear if the code is checked with Clippy itself. There is still an issue with using the old lint name in inner attributes. For inner attributes the warning gets emitted twice. I'm currently not really sure why this happens, but will try to fix this ASAP. r? @Manishearth
rust-lang/rust#53762 landed. I'll do a local test run and catch any merge issues that may have happened |
cc #2955
Waiting for rust-lang/rust#52851
The (ui-)tests need to be adapted to the tool lints, by renaming every
clippy_lint
toclippy::clippy_lint
. Also#![feature(tool_lints)]
needs to be added to the tests, untiltool_lints
are stable.