nearcore
nearcore copied to clipboard
Revisit Clippy whitelisting
We should start enabling [clippy](https://github.com/rust-lang/rust-clippy) gradually. To do that, we should first figure out which rules trigger warnings and document them. The purpose of this issue is to get a list of clippy rules that we do not follow now so that we can fix them in the future.
I assigned L1 implying that initial items should not be huge and Clippy + Rust compiler should guide us through, but if a bigger refactoring is necessary, we should decouple those into separate dedicated issues.
This issue has been automatically marked as stale because it has not had recent activity in the last 2 months. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity in the last 2 months. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
@matklad @nagisa curious what your thoughts are on this topic
While I am not a huge fan of clippy, for a big project with many developers, like nearcore
, I think enabling clippy would be a net benefit, so we should do that.
Though, in terms of "keeping the code base sane", I don't think that's the most impactful thing. I'd say we should fix #4490 and improve compile times (by auditing our deps in Cargo.lock and cutting the cruft out) first.
i definitely seen bugs being caught by clippy in CI, so I'm in favour of adding some of the clippy lints to at least CI.
I'm a big favor of clippy
. I detected many potential issues ahead of time.
It also has many useful suggestions on how to write a cleaner, more readable code.I think we should enable it by default.
This issue has been automatically marked as stale because it has not had recent activity in the last 2 months. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
Closing in favour of https://github.com/near/nearcore/issues/8145