Manishearth

rust-clippy

Rust2015–2017

Manishearth / rust-clippy

rust-clippy

A bunch of lints to catch common mistakes and improve your Rust code

Explore on GitHub Read Hacker News discussions

12Distinct people

20Mentions

0Explicit recommenders

113GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

A bunch of lints to catch common mistakes and improve your Rust code

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month20 dated mentions

Observed mentions: 2015-03-18 01:04:32 UTC to 2017-05-10 02:11:24 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
Mar 2015	2015-03-01 00:00:00 UTC	2015-04-01 00:00:00 UTC	1	1
Apr 2015	2015-04-01 00:00:00 UTC	2015-05-01 00:00:00 UTC	0	0
May 2015	2015-05-01 00:00:00 UTC	2015-06-01 00:00:00 UTC	0	0
Jun 2015	2015-06-01 00:00:00 UTC	2015-07-01 00:00:00 UTC	0	0
Jul 2015	2015-07-01 00:00:00 UTC	2015-08-01 00:00:00 UTC	0	0
Aug 2015	2015-08-01 00:00:00 UTC	2015-09-01 00:00:00 UTC	0	0
Sep 2015	2015-09-01 00:00:00 UTC	2015-10-01 00:00:00 UTC	0	0
Oct 2015	2015-10-01 00:00:00 UTC	2015-11-01 00:00:00 UTC	1	1
Nov 2015	2015-11-01 00:00:00 UTC	2015-12-01 00:00:00 UTC	0	0
Dec 2015	2015-12-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	0	0
Jan 2016	2016-01-01 00:00:00 UTC	2016-02-01 00:00:00 UTC	0	0
Feb 2016	2016-02-01 00:00:00 UTC	2016-03-01 00:00:00 UTC	1	1
Mar 2016	2016-03-01 00:00:00 UTC	2016-04-01 00:00:00 UTC	0	0
Apr 2016	2016-04-01 00:00:00 UTC	2016-05-01 00:00:00 UTC	2	2
May 2016	2016-05-01 00:00:00 UTC	2016-06-01 00:00:00 UTC	1	1
Jun 2016	2016-06-01 00:00:00 UTC	2016-07-01 00:00:00 UTC	2	2
Jul 2016	2016-07-01 00:00:00 UTC	2016-08-01 00:00:00 UTC	1	1
Aug 2016	2016-08-01 00:00:00 UTC	2016-09-01 00:00:00 UTC	3	3
Sep 2016	2016-09-01 00:00:00 UTC	2016-10-01 00:00:00 UTC	0	0
Oct 2016	2016-10-01 00:00:00 UTC	2016-11-01 00:00:00 UTC	0	0
Nov 2016	2016-11-01 00:00:00 UTC	2016-12-01 00:00:00 UTC	2	2
Dec 2016	2016-12-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	2	2
Jan 2017	2017-01-01 00:00:00 UTC	2017-02-01 00:00:00 UTC	1	1
Feb 2017	2017-02-01 00:00:00 UTC	2017-03-01 00:00:00 UTC	0	0
Mar 2017	2017-03-01 00:00:00 UTC	2017-04-01 00:00:00 UTC	0	0
Apr 2017	2017-04-01 00:00:00 UTC	2017-05-01 00:00:00 UTC	1	1
May 2017	2017-05-01 00:00:00 UTC	2017-06-01 00:00:00 UTC	2	2

What Hacker News says

20 sources

Manishearth·May 10, 2017

I don't think the intent is to compromise on these :) But lots of things can be made easier to learn via better tooling, better docs, or better diagnostics. Or just removing papercuts. One such thing I've recently been thinking about is https://github.com/Manishearth/rust-clippy/issues/1737 , which would be cool if it got big.

In Making a Game in Rust

tveita·May 5, 2017

Clippy has some checks for naming convention beyond what rustc and rustfmt does. Not nearly as much as https://github.com/brson/rust-api-guidelines, but the wrong_self_convention check helped me make sense of the as/to/into conventions. https://github.com/Manishearth/rust-clippy

In The Rust Libs Blitz

geofft·Apr 1, 2017

You can use some analysis tools on Rust code, because it generates C-ABI-compatible objects; for instance, I'd expect that https://github.com/agl/ctgrind would work on Rust. Looking at the MISRA-C guidelines (or more specifically, a pirated copy - are these available legitimately to the public?), it seems like about half of them aren't problems in Rust, because it's warning you about stupid things in C that can't be fixed for legacy reasons, and half of them are things that could be caught with a linter / static analysis tool like https://github.com/Manishearth/rust-clippy . Do you think building something that implements as many of the MISRA-C checks as possible is useful progress towards the high-assurance Rust goal?

In Tor in a safer language: Network team update from Amsterdam

kibwen·Jan 12, 2017

I admit that I'm having a hard time seeing this criticism as anything but overblown. Finding usage of unwrap is trivially easy via textual search. Furthermore, Clippy can be used to automatically forbid usage of unwrap for your entire team ( https://github.com/Manishearth/rust-clippy/wiki#option_unwra... ). Furthermore, even when you hit a panic, it tells you which line of code in which file triggered it so that you can fix it immediately. Furthermore, the Rust community has a strong and long-entrenched proscription against libraries which unwrap rather than handle errors. We can agree in the cynical interpretation of the laziness of programmers, but the mitigations in this case are so trivial, and the stakes so low, that focusing on unwrap as a point of contention is a poor use of energy.

In Announcing Tokio 0.1

Manishearth·Dec 17, 2016

There's actually some interesting discussion about making Clippy suggest ? instead of try: https://github.com/Manishearth/rust-clippy/issues/1361

In Stroustrup's Rule and Layering Over Time in Rust

stymaar·Dec 17, 2016

> Can you evolve your syntax as people get used to it? Not only are you adding work to your parser, but people who use your language also have to deal with the multiple iterations of the syntax that linger in various codebases. Clippy[1] helps a lot in this case, it helps people writting idiomatic Rust and it's updated when new syntaxes introduces new ways to do stuff, so the old one is deprecated _de facto_. [1] https://github.com/Manishearth/rust-clippy

In Stroustrup's Rule and Layering Over Time in Rust

Manishearth·Nov 18, 2016

This is basically what https://github.com/Manishearth/rust-clippy/wiki#option_unwra... does It doesn't work transitively (so if a crate you depend on unwraps you can't protect yourself), but https://github.com/llogiq/metacollect plans to fix that

In Rust and the Future of Systems Programming [video]

bumblebeard·Nov 16, 2016

For those not familiar with Clippy: https://github.com/Manishearth/rust-clippy It's a very useful tool; the main thing about it that annoys me is that it only works with nightly.

In Rust and the Future of Systems Programming [video]

killercup·Aug 24, 2016

Heard a talk about this at the last Elixir meetup in Cologne, looks pretty amazing – especially because of the focus on great explanations. (Should copy more lints from https://github.com/Manishearth/rust-clippy though! ;))

In Credo: Static code analysis for Elixir with a focus on consistency and teaching

GolDDranks·Aug 10, 2016

The joke's on you: Clippy – A bunch of lints to catch common mistakes and improve your Rust code https://github.com/Manishearth/rust-clippy

In Shape of errors to come

steveklabnik·Aug 10, 2016

https://github.com/Manishearth/rust-clippy

In Shape of errors to come

Manishearth·Jul 16, 2016

I disagree. I recognize that the author is writing based on their experiences, but that should not paint all contributors that way. I'm involved in two projects (Rust, Servo) which have immense numbers of contributions from volunteers. Both have mentorship programs (Servo's is more evolved, Rust's is getting on its feet). In Servo we spend a lot of time mentoring people. In return, once every few new contributors we get someone who sticks around, and perhaps even works on major things. This saves ton of time. I haven't ever measured this formally, but by eyeballing it I'd say contributors save more time than the review process and mentorship take. I also have a personal project, rust-clippy (http://github.com/manishearth/rust-clippy/). It started out as my own thing, and I merged with another similar project and got a co-maintainer. It wa

Read the rest

s mostly the two of us working on it. We could have gotten it to the stage which it is at now, but it would have taken forever. At one point I started tagging issues as easy/medium/hard, and wrote some documentation for newbies wanting to contribute. I advertised this a bit in the appropriate forums, and now I have tons of contributors; three of which have become maintainers (they still contribute a lot), and a couple others who frequently contribute. I don't have much time to work on this project these days, but it has grown so much without me needing to put much time in it at all. These days I mostly review PRs and take part in discussions, but rarely write code for it. The project is now a tool with more than 150 lints which most of the Rust community uses and loves. It would not have gotten there without the contributors. If you'd like your project to be mroe receptive to new contributors, I have a blog post I once wrote for this: http://manishearth.github.io/blog/2016/01/03/making-your-ope.... Many of the tips there don't require much effort -- it's either a one-time thing you have to do, or a change in process that doesn't make the process longer. Aside: Often a distinction between "contributor" and "maintainer" is made, and this is cropping up in this thread too. In clippy this has never really been a thing. We have maintainers, but when someone becomes a maintainer they don't really do anything different -- they don't take on more responsibilities. Rather, most of the contributors I have ramp up from working on individual issues to reviewing and doing maintainer-y things, and once we think they've got the gist of it we give them merge powers. In Servo/Rust we also have a similar continuum -- we have folks who take part in review without having review access ("review access" is the ability to tell our autoland bot that something is reviewed and ready to test/merge), and at some point they are given reviewer permissions. So there is of course a difference in the powers available to contributors and maintainers, but in the projects I work on the most there's not much of a difference in what they do; maintainers don't have additional responsibilities, they just have powers which help they carry out what they were doing as a contributor anyway.

In Contributors do not save time

dikaiosune·Jun 13, 2016

The regex crate in Rust works perfectly well on stable, AFAIK. The author has improved the runtime-constructed regexes to be much faster, while those same improvements haven't yet made it to the compile-time macro-constructed regexes. So, to get the most speed, one gives up having a hard compiler error when using an invalid regex literal. That said, the clippy tool (https://github.com/Manishearth/rust-clippy) can do compile-time verification of regex literals, but it depends on nightly Rust because it relies on deep integration with unstable compiler internals. (The regex crate also has a new optional nightly-only SIMD-accelerated algorithm, but it's otherwise fully functional on stable.) Re: nightly features, I agree that there are several things which Rust really needs to stabilize to achieve many of its goals (stable SIMD, inline assem

Read the rest

bly, procedural macros, stable custom allocator support, the Rust Language Server for IDE integration, etc etc etc). Now that the major compiler internals refactoring of the last year is nearly complete, my understanding is that we may start to see more aggressive progress on some of those items which keep pushing users to nightly Rust.

In “Safe C++ Subset” Is Vapourware

dikaiosune·Jun 2, 2016

Not nearly as much as intellij. However the "linting" in this case is really just highlighting for compiler warnings and errors which are quite good in Rust. That said, you can use clippy (https://github.com/Manishearth/rust-clippy) to get some pretty solid static code analysis as a compiler plug in. Also, I am very closely following the progress of the rust intellij project, it's coming along nicely.

In Sapper, a lightweight web framework written in Rust

killercup·May 2, 2016

Yes, several of the optimizations of the dynamic regexes aren't available in the compile-time version. (It doesn't even have a DFA, IIRC.) There is [a lint][1] which checks that your regular expressions are valid (at compile time), though. [1]: https://github.com/Manishearth/rust-clippy/wiki#invalid_rege...

In Go bindings to Rust's regex engine

Showing the 15 most recent of 20 sources. Enable JavaScript to search and browse every indexed mention.