Some extra pedantic checks?

[Licenser]

Hey, I would love to add a few lints to that which are fairly super pedantic. We use them (or rather a shell script that checks for them :P) at the moment to ensure error handling/non crashy behaviour in our codebase they sum up to:

• no unwrap
• no unimplemented
• no unreachable
• no panic
• no let _ on results.
• no expect
• no dbg!
• no std::process::exit
• no bracket access [....]

but before I go ahead I'd like to get an opinion of those would be accepted?

[flip1995]

Some of those lints already exist, most others are low hanging fruits. Have a look at the restriction lint group. For the lints that don't exist yet: Yes they would be accepted in exactly that restriction group.

Lints that already exist:

• no unwrap [1] [2]
• no unimplemented [1]
• no unreachable¹ Additional restrictions #4657
• no panic¹ Additional restrictions #4657
• no let _ on results / must_use⁴
• no expect² Additional restrictions #4657
• no dbg! [1]
• no std::process::exit³
• no bracket access [1] (Will not warn on guaranteed safe slicing of arrays)

---

¹easy extension of unimplemented
²easy extension of unwrap lints
³should be fairly easy to implement (just a function path check)
⁴may be a bit harder to implement, dependent on how complicated it is to find out if a type is must_use

---

If you want to implement the other lints you're more than welcome! Have a look at https://github.com/rust-lang/rust-clippy/blob/master/doc/adding_lints.md first, and if you have any questions, don't hesitate to ask!

[Licenser]

I opend #4697 for exit but I think the let _... = one is a bit too complex for me at the moment. Since all the rest is done, would it make sense to split that out into an extra, more focused, issue and close this?

[llogiq]

We have a check for #[must_use] types in functions.rs already (IIRC is_must_use_ty(cx, ty), we best move this to utils/mod.rs), that you can call with the result of an expr_ty(cx, _) on the initializer.

[flip1995]

Since the let _ = ... lint is the only one missing in this issue, I moved it to #4812