Currently, the CI pipeline triggers `Lintcheck` for all PRs. However,
this check takes significant amount of time and seems unnecessary for
some certain directories that are frequently updated.
r? flip1995
changelog: none
Add a new lint `doc_overindented_list_items` to detect and fix list
items
in docs that are overindented.
For example,
```rs
/// - first line
/// second line
fn foo() {}
```
this would be fixed to:
```rs
/// - first line
/// second line
fn foo() {}
```
This lint improves readabiliy and consistency in doc.
---
- \[x] Followed [lint naming conventions][lint_naming]
- \[x] Added passing UI tests (including committed `.stderr` file)
- \[x] `cargo test` passes locally
- \[x] Executed `cargo dev update_lints`
- \[x] Added lint documentation
- \[x] Run `cargo dev fmt`
[lint_naming]:
https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints
changelog: [`doc_overindented_list_items`]: Added a new lint that
detects overindented list items in docs
fixes: #13601
Add a new lint `doc_overindented_list_items` to detect and fix list items
in docs that are overindented.
For example,
```rs
/// - first line
/// second line
fn foo() {}
```
this would be fixed to:
```rs
/// - first line
/// second line
fn foo() {}
```
This lint improves readabiliy and consistency in doc.
fix#14034
The currect implementation of `obfuscated_if_else` sometimes makes
incorrect suggestions when the original code have side effects (see the
example in the above issue). I think this can be fixed by changing the
applicability depending on whether it can have side effects or not.
changelog: [`obfuscated_if_else`]: change applicability when the
original code can have side effects
Removing the `.as_ref()` or `.as_mut()` as the top-level expression in a
closure may change the type of the result. In this case, it may be
better not to lint rather than proposing a fix that would not work.
I opened https://github.com/rust-lang/rust-clippy/pull/13896 before.
However, I found that there're more cases where Clippy suggests to use
modules that belong to the `std` crate even in a `no_std` environment.
Therefore, this PR include the changes I've made in #13896 and new
changes to fix cases I found this time to prevent wrong suggestions in
`no_std` environments as well.
changelog: [`redundant_closure`]: correct suggestion in `no_std`
changelog: [`repeat_vec_with_capacity`]: correct suggestion in `no_std`
changelog: [`single_range_in_vec_init`]: don't emit suggestion to use
`Vec` in `no_std`
changelog: [`drain_collect`]: correct suggestion in `no_std`
changelog: [`map_with_unused_argument_over_ranges`]: correct suggestion
in `no_std`
also close#13895
Uplift `clippy::double_neg` lint as `double_negations`
Warns about cases like this:
```rust
fn main() {
let x = 1;
let _b = --x; //~ WARN use of a double negation
}
```
The intent is to keep people from thinking that `--x` is a prefix decrement operator. `++x`, `x++` and `x--` are invalid expressions and already have a helpful diagnostic.
I didn't add a machine-applicable suggestion to the lint because it's not entirely clear what the programmer was trying to achieve with the `--x` operation. The code that triggers the lint should always be reviewed manually.
Closes#82987
Receivers which are references to `Option` and `Result`, or who
implement `Deref` to one of those types, will be linted as well.
changelog: [`unnecessary_map_or`]: work with ref and `Deref` to `Option`
and `Result` as well
Fixes#14023
**Note:** this patch must be merged after #13998 – only the second
commit must be reviewed, the first one repeats the patch in #13998 for
mergeability reasons.
I noticed that default PR messages could pass the changelog checking CI.
For example, if a PR is submitted without modifying the PR template, the
following line is mistakenly treated as a valid changelog by the CI:
```
changelog: [`lint_name`]: your change
```
r? flip1995
changelog: none
Get rid of `mir::Const::from_ty_const`
This function is strange, because it turns valtrees into `mir::Const::Value`, but the rest of the const variants stay as type system consts.
All of the callsites except for one in `instsimplify` (array length simplification of `ptr_metadata` call) just go through the valtree arm of the function, so it's easier to just create a `mir::Const` directly for those.
For the instsimplify case, if we have a type system const we should *keep* having a type system const, rather than turning it into a `mir::Const::Value`; it doesn't really matter in practice, though, bc `usize` has no padding, but it feels more principled.
part of https://github.com/rust-lang/rust-clippy/issues/9100
The `obfuscated_if_else` lint currently only triggers for the pattern
`.then_some(..).unwrap_or(..)`, but there're other cases where this lint
should be triggered, one of which is `.then(..).unwrap_or(..)`.
changelog: [`obfuscated_if_else`]: trigger lint for the
`.then(..).unwrap_or(..)` pattern as well
fixes#12895
detects usage of `once_cell::sync::Lazy` and `lazy_static!`,
recommending usage of `std::sync::LazyLock` instead
Many thanks to @J-ZhengLi for putting in most of the work in #12968
----
changelog: new lint [`non_std_lazy_statics`]
changelog: none
`x & 15 == 0` is not equivalent to `x.trailing_zeros() > 4`, as `x =
0b10000` is true for the former and false for the latter.
In fact, clippy itself suggests the following:
```rust
pub fn src(x: i32) -> bool {
x & 15 == 0 // ~error: bit mask could be simplified with a call to `trailing_zeros`
^^^^^^^^^^^ help: try: `x.trailing_zeros() >= 4`
}
```
