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

Break out lints into a separate binary #1027

Closed
kamalmarhubi opened this issue Jun 1, 2016 · 4 comments
Closed

Break out lints into a separate binary #1027

kamalmarhubi opened this issue Jun 1, 2016 · 4 comments

Comments

@kamalmarhubi
Copy link
Contributor

kamalmarhubi commented Jun 1, 2016

I just skimmed the open 1.0 blockers to get an idea of what's out there. #209 (Check for license) jumped out as one that is more like linting than formatting. This goes along with TODO / FIXME checking in my opinion.

From my perspective as a user, this functionality should be in a separate tool, let's say rustlint for lack of a better name.

In #798 (comment), @nrc said

Yeah, I have been considering a less monolithic vision recently. I'm not exactly how it should work and how to make it ergonomic though.

I understand an overarching motivation from @nrc's point of view is to replace make tidy in the rust repo (#20). We can still get there by breaking out those lints into a separate binary that lives under the rustfmt repo—most easily in the same crate. I haven't looked at control flow to see how mixed in these features are, but it seems like it should be possible given the code is already there.

@nrc
Copy link
Member

nrc commented Jun 1, 2016

What is the advantage of a separate binary over configuration options for these things?

@kamalmarhubi
Copy link
Contributor Author

I think that's not really the right question. The only pro of a single binary I see is that it's the way it's done now. Given a tool that is called rustfmt and whose tag line is Formats Rust code, I don't really expect it to give me any warnings about anything. As I wrote in #798:

rustfmt is a formatting tool: it takes code in, and spits out better formatted code that abides by conventions. Reporting style deviations belongs in a lint tool.

This fits expectations across language ecosystems: I can't think of a language where a formating tool produces warnings about style issues. Ones I've looked at: clang-format, gofmt, autopep8.

@nrc
Copy link
Member

nrc commented Jun 1, 2016

The pro is that from a user's point of view, they only need one tool instead of several. That convenience is important. I would argue that any IDE is a formatting tool that produces warnings about all sorts of errors, so there is (sort of) precedent.

Anyway, I'm open to the idea of multiple tools, just want to properly evaluate the pros and cons.

@kamalmarhubi
Copy link
Contributor Author

kamalmarhubi commented Jun 1, 2016

Anyway, I'm open to the idea of multiple tools, just want to properly evaluate the pros and cons.

👍 this makes sense!

@nrc nrc closed this as completed Nov 2, 2017
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

No branches or pull requests

2 participants