Embark's standard lints

[repi]

Background

This issue tracks which Rust and Clippy lints we currently use as default for all of our internal and external crates. We have a common base of lints that we configure the same everywhere that is more opinionated than the Rust and Clippy defaults and geared towards how we prefer to (currently) write & maintain Rust code.

Individual crates are able to, and often do override some of these defaults, either on a crate level, or for specific modules or functions. But we still find it helpful to have a standard across everything to keep the code high quality and generally working the same way.

Lint configuration

We currently have two ways to enable our configured lints:

1. Through copy'n'pasting https://github.com/EmbarkStudios/rust-ecosystem/blob/main/lints.rs into every crate
2. Through a .cargo/config.toml section: https://github.com/EmbarkStudios/rust-ecosystem/blob/main/lints.toml

Traditionally we've used option 1, but are testing and converting more to option 2 as it is much easier to just have a single configuration file with everything.

We hope to later in 2021 have proper first-class support for a lints.toml or [lints] section in Cargo and switch to that, but progress for it has been slow. Tracked in:

• Be able to disable/enable Clippy lints globally #22
• Support defining enabled and disabled lints in a configuration file rust-lang/cargo#5034
• [Roadmap] Configuration file for lints rust-lang/rust-clippy#6625.

Lints of interests

Testing / being discussed

• Add: clippy::needless_pass_by_value - helped us catch a lot of unnecessary : Vec<T> arguments and replace them with : &[T], saving a lot of calls to .clone() (very common trap for rust beginners to fall into). quite intrusive change for lots of crates though so safer to do separtely
• Add: rustdoc::missing_crate_level_docs

Blocked

List of Clippy lints we are interested in using, but that have issues or are not mature / specific enough yet for inclusion.

• clippy::use_self - blocked on clippy::use_self has too many false positives #53
• clippy::unnecessary_wraps
• clippy::option_if_let_else - blocked on:
  • option_if_let_else suggests map_or instead of map_or_else even if else branch contains a function call rust-lang/rust-clippy#5821
  • option_if_let_else suggestion inapplicable when mutable borrow or owned value is used in both branches rust-lang/rust-clippy#5822
  • Invalid suggestion of option_if_let_else causes a compilation error error[E0382]: Borrow of moved value rust-lang/rust-clippy#6737
  • option_if_let_else suggestion does not compile rust-lang/rust-clippy#6137
• clippy::wildcard_enum_match_arm - blocked on wildcard_enum_match_arm fail with non-exhaustive enums and OR patterns rust-lang/rust-clippy#6862
• clippy::print_stdout / clippy::print_stderr - ineffective due to EarlyLintPass::check_mac() is not called in non-toplevel modules rust-lang/rust-clippy#5721

[repi]

Filed EmbarkStudios/opensource#35 to start using the template in all of our current open source repos

[repi]

#60 is a PR draft and discussion about potential additions and removals for v0.3

[repi]

We have a v0.3 of the lints now also that adds the following ones that we've verified across multiple of our codebases 🎉

• Add: map_err_ignore - prevents loosing error context and works well in Ark, easy to ignore when needed
• Add: match_same_arms - seems to work well and simplifies matching code to reduce complexity, with some exceptions.
• Add: large_types_passed_by_value - seems like a good idea, could catch some things should be boxed. no warns in Ark.
• Add: string_add - cleaner & more explicit, only 1 easy fixed warn in Ark.
• Add: string_add_assign - cleaner & more explicit, only 1 easy fixed warn in Ark.
• Add: explicit_iter_loop - we already use explicit_into_iter_loop in v0.2, should enable or disable both.
• Add: unimplemented - good for stubbing out WIP code but want to avoid on main our crates & systems are live at head