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

Implement tool_lints #2977

Merged
merged 13 commits into from
Sep 1, 2018
Merged

Implement tool_lints #2977

merged 13 commits into from
Sep 1, 2018

Conversation

flip1995
Copy link
Member

@flip1995 flip1995 commented Jul 30, 2018

cc #2955

Waiting for rust-lang/rust#52851

The (ui-)tests need to be adapted to the tool lints, by renaming every clippy_lint to clippy::clippy_lint. Also #![feature(tool_lints)] needs to be added to the tests, until tool_lints are stable.

#[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)]
Copy link
Member Author

@flip1995 flip1995 Jul 30, 2018

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

Copy link
Contributor

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};
Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Member Author

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.

Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Member Author

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

Copy link
Contributor

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

Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request Aug 1, 2018
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
@Manishearth
Copy link
Member

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 clippy::foo and foo and warn on the latter. Or we can register deprecated aliases or something here. Not sure how to best make this work.

pietroalbini added a commit to pietroalbini/rust that referenced this pull request Aug 1, 2018
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
@flip1995
Copy link
Member Author

flip1995 commented Aug 1, 2018

You can still use the declare_lint! macro and nothing would change. If we switch to the declare_tool_lint! macro the old ones won't work anymore. That is because I implemented this macro to just concat the tool name onto the lint name. This means there is no good way for rustc to allow both IMO.

I could have added a double check for tool_name::lint_name and just lint_name to the compiler and remove it in several weeks again. But then most of the handling of the tool_attributes and tool_lints should be done by the tools and not the compiler, like the RFC stated.

My solution to this would be to write a lint for occurrences of #[cfg_attr(feature="cargo-clippy", ...) before making this change (And maybe wait a week or two).

We also need a lint for unknown_clippy_lints in the near future, after landing this.

...I should list this in #2955

@flip1995
Copy link
Member Author

flip1995 commented Aug 1, 2018

Whoops my update script for the ui-tests slipped a little bit there. I'll reduce the number of lines changed a bit 😄

@Manishearth
Copy link
Member

@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"

@Manishearth
Copy link
Member

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 😄

@flip1995
Copy link
Member Author

flip1995 commented Aug 1, 2018

I think I finished the ui-tests update. I looked through every .stderr file and github reports +2,243 −2,243 for the two stderr commits. 🎉

@flip1995
Copy link
Member Author

flip1995 commented Aug 1, 2018

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 annoying exhausting 😄)

for tool lint groups we can temporarily make the registration API ask for a deprecated fallback name

That makes sense to me.

@Manishearth
Copy link
Member

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.

Yes, this is only if you're running with clippy.

(I'm sorry, if I'm missing the point of doing this in the compiler. Doing the ui-tests update was pretty annoying exhausting smile)

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.

@flip1995
Copy link
Member Author

flip1995 commented Aug 1, 2018

Ahh, I got it now! Thanks for the clarification!

@flip1995
Copy link
Member Author

flip1995 commented Aug 1, 2018

Travis should be green with the next nightly now. Do not merge this until the backwards compatibility is implemented in rustc.

@flip1995 flip1995 closed this Aug 2, 2018
@flip1995 flip1995 reopened this Aug 2, 2018
@phansch phansch closed this Aug 6, 2018
@phansch phansch reopened this Aug 6, 2018
@phansch
Copy link
Member

phansch commented Aug 6, 2018

@flip1995 looks like some conflicts appeared

@flip1995
Copy link
Member Author

flip1995 commented Aug 6, 2018

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.

@oli-obk
Copy link
Contributor

oli-obk commented Aug 23, 2018

ping @flip1995 any update on the backwards compat?

@flip1995
Copy link
Member Author

I will open a PR in rust-lang/rust by the end of this week

@flip1995
Copy link
Member Author

It's almost finished, just need to prettify it a little. Sorry for the delay.

@flip1995 flip1995 force-pushed the tool_lints branch 2 times, most recently from a3aab0b to cbd178b Compare August 28, 2018 09:54
@Manishearth
Copy link
Member

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)

@flip1995 flip1995 changed the title WIP: Implement tool_lints Implement tool_lints Aug 30, 2018
bors added a commit to rust-lang/rust that referenced this pull request Sep 1, 2018
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
@Manishearth Manishearth merged commit c81d70e into rust-lang:master Sep 1, 2018
@Manishearth
Copy link
Member

rust-lang/rust#53762 landed. I'll do a local test run and catch any merge issues that may have happened

@flip1995 flip1995 deleted the tool_lints branch September 6, 2018 10:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants