Skip to content
This repository was archived by the owner on Nov 24, 2023. It is now read-only.

Apply only certain fixes #36

Closed
Dushistov opened this issue Jul 8, 2017 · 6 comments
Closed

Apply only certain fixes #36

Dushistov opened this issue Jul 8, 2017 · 6 comments
Labels
enhancement help wanted postponed Later is better than never, right?

Comments

@Dushistov
Copy link

I can not find any docs about functionality applying only certain fixes,
so here is feature request: it would be nice to filter possible fixes and applying only some classes of them.

For example, during development phase you can have bunch of warning unused something,
this is ok on development stage, but should be fixed on stabializing feature stage.

Also, for example I read about rustfix here and would like to try to fix use issues, but only for them.

So, it would be great to have something like --ignore-class=unused and --apply-only-for-class=use command line arguments.

@killercup
Copy link
Member

killercup commented Jul 8, 2017

Yes, whitelisting is certainly something we should add to ensure that casual users only ever get suggestions that work! I think it'd be good to hard-code some known-good-lints and only apply these unless the user sets --experimental. This will also make --yolo more stable. (I've previously talked with The Clippy Gang and the Dev Tools Team about this.)

Would you like to work on? I think a good first PR would add the whitelist and then .filter the suggestions here.

Dushistov added a commit to Dushistov/rustfix that referenced this issue Jul 24, 2017
@shepmaster
Copy link
Member

I want to +1 the ability to only automatically fix a single specific lint at a time.

whitelisting is certainly something we should add to ensure that casual users only ever get suggestions that work

I read the original comment as something different. Your comment seems to be focused on "safe" vs "scary" fixes. That's also sounds useful, but I don't think it's this issue.


My preferred workflow when introducing new lints to an existing code base is:

  1. Install the tool.
  2. Have the tool generate a "TODO" file that marks all existing lint violations as ignored.
  • Ideally this file is split into two dimensions: file and lint type.

At this point, I commit and push this progress. This prevents any files from getting worse. Then, the team cycles on the following steps:

  1. Pick a single lint that is being ignored.
  2. Fix all of or a subset of the files for that one lint, and push it.

What's interesting to note is that this entire process usually repeats when a new version of the linting tool is released, as this often introduces new lints that we have been unknowingly violating.

When something is automatic, I want to fix it, then manually perform a cargo test and a git diff to review it myself. This --only=use option would allow that.

This is strongly influenced by RuboCop.

@killercup
Copy link
Member

@shepmaster sorry if my last comment was confusing! I was thinking about the implementation of the whitelist, and that we can use its default value to show which lint suggestions we consider to be stable.

Also: Thanks for reminding me to look to get #37 merged :)

@shepmaster
Copy link
Member

I was thinking about the implementation of the whitelist

Ok, and it sounds like that's something else besides this issue (which sounds correct to me). Is there a link to the issue for the whitelist you are thinking about?

@killercup
Copy link
Member

killercup commented Oct 20, 2017 via email

@killercup
Copy link
Member

FYI rust-lang/rust#45484 just landed which makes identifying lint names in diagnostic output way easier

bors bot added a commit that referenced this issue Nov 7, 2017
42: Add flag to only apply certain lints/errors' suggestions  r=killercup a=oli-obk

cc #36
@killercup killercup added the postponed Later is better than never, right? label May 4, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement help wanted postponed Later is better than never, right?
Projects
None yet
Development

No branches or pull requests

3 participants