Lint for bool to integer casts in `cast_lossless`
The lint description says
> Checks for casts between *numerical* types that may be replaced by safe conversion functions.
Which is strictly speaking being violated here, but it seems within the spirit of the lint. I think it is still a useful lint to have, and having a different lint for just this feels excessive. Thoughts?
Fixes#7947
changelog: Lint for bool to integer casts in [`cast_lossless`]
Author improvements
changelog: none
Various aspects of the author implementation are re-imagined to be much less repetitive. Also fixes some bugs. I hope this makes author more fun to work on for future contributors.
The last commit is pretty heavy but I tried to at least separate some changes so that the test file diffs per commit are simple.
* Finding pattern slices for `avoidable_slice_indexing`
* `avoidable_slice_indexing` analysing slice usage
* Add configuration to `avoidable_slice_indexing`
* Emitting `avoidable_slice_indexing` with suggestions
* Dogfooding and fixing bugs
* Add ui-toml test for `avoidable_slice_indexing`
* Correctly suggest `ref` keywords for `avoidable_slice_indexing`
* Test and document `mut` for `avoid_slice_indexing`
* Handle macros with `avoidable_slice_indexing` lint
* Ignore slices with sub patterns in `avoidable_slice_indexing`
* Update lint description for `avoidable_slice_indexing`
* Move `avoidable_slice_indexing` to nursery
* Added more tests for `avoidable_slice_indexing`
* Update documentation and message for `avoidable_slice_indexing`
* Teach `avoidable_slice_indexing` about `HirId`s and `Visitors`
* Rename lint to `index_refutable_slice` and connected config
Add Clippy version to Clippy's lint list
Hey, hey, the semester is finally over, and I wanted to get back into hacking on Clippy. It has also been some time since our metadata collection monster has been feed. So, this PR adds a new attribute `clippy::version` to document which version a lint was stabilized. I considered using `git blame` but that would be very hacky and probably not accurate.
I'm also thinking that this attribute can be used to have a `clippy::nightly` lint group which is allow-by-default that delays setting the actual lint group until the defined version is reached. Just something to consider regarding #6623🙃
This PR only adds the version to 4 lints to keep it reviewable. I'll do a followup PR to add the version to other lints if the implementation is accepted 🙃
Also, mobile approved xD
---
r? `@flip1995`
cc: #7172closes: #6492
changelog: [Clippy's lint list](https://rust-lang.github.io/rust-clippy/master/index.html) now displays the version a lint was added. 🎉
---
Example lint declaration after this update:
```rs
declare_clippy_lint! {
/// [...]
///
/// ### Example
/// ```rust
/// // Bad
/// let x = 3.14;
/// // Good
/// let x = std::f32::consts::PI;
/// ```
#[clippy::version = "pre 1.29.0"]
pub APPROX_CONSTANT,
correctness,
"the approximate of a known float constant (in `std::fXX::consts`)"
}
```
Fix `explicit_counter_loop` suggestion for non-usize types
changelog: Add a new suggestion for non-usize types in [`explicit_counter_loop`]
closes: #7920
Fix suggestion for deref expressions in redundant_pattern_matching
changelog: Fix suggestion for deref expressions in [`redundant_pattern_matching`]
closes: #7921
Replace `in_macro` usage with `from_expansion`
changelog: none
Generally replace `in_macro(span)` with `span.from_expansion()`. If we're just trying to avoid expanded code, this seems more appropriate because any kind of expanded code is prone to false positives. One place I did not touch is `macro_use.rs`. I think this lint could use a rewrite so I moved `in_macro` there, the only place it is still used.
Prevent clippy::needless_lifetimes false positive in async function definition
Scan `OpaqueDef` bounds for lifetimes as well. Those `OpaqueDef` instances are generated while desugaring an `async` function definition.
This fixes#7893
changelog: Prevent [`clippy::needless_lifetimes`] false positive in `async` function definition
Fix manual_assert and match_wild_err_arm for `#![no_std]` and Rust 2021
Rust 2015 `std::panic!` has a wrapping block while `core::panic!` and Rust 2021 `std::panic!` does not. See rust-lang/rust#88919 for details.
Note that the test won't pass until clippy changes in rust-lang/rust#88860 is synced.
---
changelog: Fix [`manual_assert`] and [`match_wild_err_arm`] for `#![no_std]` and Rust 2021.
Fixes#7723
Unseparated literal suffix
Closes#7658
Since `literal_suffix` style is opinionated, we should disable by default and only enforce if it's stated as so.
changelog: [`unseparated_literal_suffix`] is renamed to `literal_suffix`, adds a new configuration `literal-suffix-style` to enforce a certain style writing literal_suffix. Possible values for `literal-suffix-style`: `"separated"`, `"unseparated"`
avoid linting `possible_truncation` on bit-reducing operations
---
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: avoid linting `possible_truncation` on bit-reducing operations
update most tests to 2021 edition
Some tests would no longer work at all, so I added `edition:2015` or `edition:2018` to them.
Notably 2021 panics are not yet detected correctly. Once ready, this closes#7842.
---
changelog: none
`unseparated_literal_suffix`
This commit adds a configuration `literal-suffix-style` to enforce a
specific style for unseparated_literal_suffix. The configuration accepts
two values:
- "separated"
enforce all literals to be written separately (e.g. `123_i32`)
- "unseparated"
enforce all literals to be written as unseparated (e.g. `123i32`)
Not specifying a value means that there is no preference on style and
any style should not be warned.
