This lint will complain when you put a mutable function/method call
inside a `debug_assert` macro, because it will not be executed in
release mode, therefore it will change the execution flow, which is not
wanted.
`must_use_unit` lints unit-returning functions with a `#[must_use]`
attribute, suggesting to remove it.
`double_must_use` lints functions with a plain `#[must_use]`
attribute, but which return a type which is already `#[must_use]`,
so the attribute has no benefit.
`must_use_candidate` is a pedantic lint that lints functions and
methods that return some non-unit type that is not already
`#[must_use]` and suggests to add the annotation.
Lints when, on the RHS of a BinOp, there is a UnOp without a space
before the operator but with a space after (e.g. foo >- 1).
Signed-off-by: Nikos Filippakis <nikolaos.filippakis@cern.ch>
Remove the crates.io badge from the readme.
Installing clippy via crates.io is deprecated and rustup should be used instead, thus we should not promote crates.io here.
Don't have the entire clippy::correctness line in bold letters, I think it looks a little off.
Move the method checking into a new lint called
`redundant_closures_for_method_calls` and put it in the pedantic group.
This aspect of the lint seems more controversial than the rest.
cc #3942
* Late Lint pass, catches:
* One liner: 0 -> null -> transmute
* One liner: std:null() -> transmute
* Const (which resolves to null) -> transmute
* UI Test case for Lint
* Updated test for issue 3849, because now the lint that code generated is in Clippy.
* Expanded `const.rs` miri-based Constant Folding code, to cover
raw pointers
Add lint writing documentation
[Rendered](https://github.com/phansch/rust-clippy/blob/adding_lints/doc/adding_lints.md)
This adds a new documentation page that explains how to write Clippy
lints. It guides the reader through creating a `foo` function lint.
I plan to iterate a bit more on the prose of some sections, but I think the
general structure is fine now, so I'm looking forward to feedback =)
One thing I'm not sure about: I felt like this is too big for CONTRIBUTING.md
so I put it into a new `doc/` directory. I can imagine having more
documentation in the future, so we might even want to create a book using
mdbook instead? Or should everything go into CONTRIBUTING.md?
Further things left to do:
- [x] Link from CONTRIBUTING.md
- [x] Remove things covered in this guide from CONTRIBUTING.md
- [x] Section about `clippy::author` attribute
- [x] Run `remark-lint` on CI over the `doc` directory and fix things
* Ran automatic naming update
* Formalized rename of `cyclomatic_complexity` to `cognitive_complexity`
** Added the rename to `lib.rs`
** Added rename test
* Added warning for deprecated key `cyclomatic_complexity_threshold` and tests for it
* Added deprecation status for Clippy's builtin attribute
* Updated tests for new builtin attribute renaming
