fix#13959
The current implementation of the `write_literal` and `print_literal`
lint performs escaping for the second argument of `write!` ,`writeln!`,
`print!` and `println!` of the suggestion by first replacing `"` with
`\"`, and then replacing `\` with `\\`. Performing these replacements in
this order may lead to unnecessary backslashes being added if the
original code contains `"` (e.g. `"` -> `\\"`), potentially resulting in
a suggestion that causes the code to fail to compile.
In the issue mentioned above, it’s suggested to use raw strings as raw
strings, but implementing this would require an ad-hoc change to the
current implementation, so it has been deferred. (I'll implement this in
another PR)
changelog: [`write_literal`]: fix incorrect escaping of suggestions
changelog: [`print_literal`]: fix incorrect escaping of suggestions
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
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`
}
```
Forbid usage of `hir` `Infer` const/ty variants in ambiguous contexts
The feature `generic_arg_infer` allows providing `_` as an argument to const generics in order to infer them. This introduces a syntactic ambiguity as to whether generic arguments are type or const arguments. In order to get around this we introduced a fourth `GenericArg` variant, `Infer` used to represent `_` as an argument to generic parameters when we don't know if its a type or a const argument.
This made hir visitors that care about `TyKind::Infer` or `ConstArgKind::Infer` very error prone as checking for `TyKind::Infer`s in `visit_ty` would find *some* type infer arguments but not *all* of them as they would sometimes be lowered to `GenericArg::Infer` instead.
Additionally the `visit_infer` method would previously only visit `GenericArg::Infer` not *all* infers (e.g. `TyKind::Infer`), this made it very easy to override `visit_infer` and expect it to visit all infers when in reality it would only visit *some* infers.
---
This PR aims to fix those issues by making the `TyKind` and `ConstArgKind` types generic over whether the infer types/consts are represented by `Ty/ConstArgKind::Infer` or out of line (e.g. by a `GenericArg::Infer` or accessible by overiding `visit_infer`). We then make HIR Visitors convert all const args and types to the versions where infer vars are stored out of line and call `visit_infer` in cases where a `Ty`/`Const` would previously have had a `Ty/ConstArgKind::Infer` variant:
API Summary
```rust
enum AmbigArg {}
enum Ty/ConstArgKind<Unambig = ()> {
...
Infer(Unambig),
}
impl Ty/ConstArg {
fn try_as_ambig_ty/ct(self) -> Option<Ty/ConstArg<AmbigArg>>;
}
impl Ty/ConstArg<AmbigArg> {
fn as_unambig_ty/ct(self) -> Ty/ConstArg;
}
enum InferKind {
Ty(Ty),
Const(ConstArg),
Ambig(InferArg),
}
trait Visitor {
...
fn visit_ty/const_arg(&mut self, Ty/ConstArg<AmbigArg>) -> Self::Result;
fn visit_infer(&mut self, id: HirId, sp: Span, kind: InferKind) -> Self::Result;
}
// blanket impl'd, not meant to be overriden
trait VisitorExt {
fn visit_ty/const_arg_unambig(&mut self, Ty/ConstArg) -> Self::Result;
}
fn walk_unambig_ty/const_arg(&mut V, Ty/ConstArg) -> Self::Result;
fn walk_ty/const_arg(&mut V, Ty/ConstArg<AmbigArg>) -> Self::Result;
```
The end result is that `visit_infer` visits *all* infer args and is also the *only* way to visit an infer arg, `visit_ty` and `visit_const_arg` can now no longer encounter a `Ty/ConstArgKind::Infer`. Representing this in the type system means that it is now very difficult to mess things up, either accessing `TyKind::Infer` "just works" and you won't miss *some* type infers- or it doesn't work and you have to look at `visit_infer` or some `GenericArg::Infer` which forces you to think about the full complexity involved.
Unfortunately there is no lint right now about explicitly matching on uninhabited variants, I can't find the context for why this is the case 🤷♀️
I'm not convinced the framing of un/ambig ty/consts is necessarily the right one but I'm not sure what would be better. I somewhat like calling them full/partial types based on the fact that `Ty<Partial>`/`Ty<Full>` directly specifies how many of the type kinds are actually represented compared to `Ty<Ambig>` which which leaves that to the reader to figure out based on the logical consequences of it the type being in an ambiguous position.
---
tool changes have been modified in their own commits for easier reviewing by anyone getting cc'd from subtree changes. I also attempted to split out "bug fixes arising from the refactoring" into their own commit so they arent lumped in with a big general refactor commit
Fixes#112110
