| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
The end goal is to eliminate `Map` altogether.
I added a `hir_` prefix to all of them, that seemed simplest. The
exceptions are `module_items` which became `hir_module_free_items` because
there was already a `hir_module_items`, and `items` which became
`hir_free_items` for consistency with `hir_module_free_items`.
|
|
|
|
|
|
By default, do not lint `.unwrap()` and `.expect(…)` in always const
contexts, as a failure would be detected at compile time anyway.
New options `allow_expect_in_consts` and `allow_unwrap_in_consts`,
defaulting to `true`, can be turned unset to still lint in always const
contexts.
|
|
|
|
of pedantic (#14027)
While extending the `option_map_or_err_ok` lint (warn by default,
"style") to recognize η-expanded forms of `Ok`, as in
```rust
// Should suggest `opt.ok_or("foobar")`
let _ = opt.map_or(Err("foobar"), |x| Ok(x));
```
I discovered that the `manual_ok_or` lint (allow by default, "pedantic")
already covered exactly the cases handled by `option_map_or_err_ok`,
including the one I was adding. Apparently, `option_map_or_err_ok` was
added without realizing that the lint already existed under the
`manual_ok_or` name. As a matter of fact, artifacts of this second lint
were even present in the first lint `stderr` file and went unnoticed for
more than a year.
This PR:
- deprecates `option_map_or_err_ok` with a message saying to use
`manual_ok_or`
- moves `manual_ok_or` from "pedantic" to "style" (the category in which
`option_map_or_err_ok` was)
In addition, I think that this lint, which is short, machine applicable,
and leads to shorter and clearer code with less arguments (`Ok`
disappears) and the removal of one level of call (`Err(x)` is replaced
by `x`), is a reason by itself to be in "style".
changelog: [`option_map_or_err_ok` and `manual_ok_or`]: move
`manual_ok_or` from "pedantic" to "style", and deprecate the redundant
style lint `option_map_or_err_ok`.
|
|
clippy-subtree-update
|
|
|
|
`rustc_middle` is a huge crate and it's always good to move stuff out of
it. There are lots of similar methods already on `Span`, so these two
functions, `in_external_macro` and `is_from_async_await`, fit right in.
The diff is big because `in_external_macro` is used a lot by clippy
lints.
|
|
|
|
|
|
Closes #11434 by moving `format_push_string` and `format_collect` to
pedantic.
changelog: Move `format_push_string` and `format_collect` to pedantic
|
|
clippy-subtree-update
|
|
|
|
resurrection of https://github.com/rust-lang/rust-clippy/pull/10984
fixes https://github.com/rust-lang/rust-clippy/issues/10981
changelog: [`sliced_string_as_bytes`]: add new lint
`sliced_string_as_bytes`
|
|
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
|
|
|
|
|
|
|
|
|
|
`manual_ok_or` covers the same case that were covered by
`option_map_or_err_ok` which is not deprecated. The latter was in the
"style" category. Also, the lint is machine applicable, and leads to
shorter and more readable code, so "style" is appropriate.
The only difference is that the η-expanded form of `Result::Ok()` was
not covered by `option_map_or_err_ok` while it is by `manual_ok_or`, so
the category change may expose some new occurrences.
|
|
|
|
A multipart suggestion will be used whenever the method call can be
replaced by another one with the first argument removed. It helps place
the new method call in context, especially when it is part of a larger
expression.
This fixes #13995 by applying a suggestion made by @y21.
r? @y21
changelog: [`unnecessary_map_or`]: better representation of suggestions
by placing them in context
|
|
A multipart suggestion will be used whenever the method call can be
replaced by another one with the first argument removed. It helps place
the new method call in context, especially when it is part of a larger
expression.
|
|
|
|
|
|
|
|
clippy-subtree-update
|
|
This builds upon the lint for `str::as_bytes()`, and also covers
needless uses of the iterator version `str::bytes()`.
|
|
We are checking that we are calling the `as_bytes()` method of `String`
or `str`. Checking that it returns a `slice()` does not add anything.
|
|
|
|
|
|
clippy-subtree-update
|
|
|
|
|
|
- `ControlFlow::map_break()`
- `ControlFlow::map_continue()`
- `Iterator::map()`
|
|
The new cases are `x.map(f)` and `x.map_err(f)` when `f` is `Into::into`
or `From::from` with the same input and output types.
|
|
clippy-subtree-update
|
|
|
|
|
|
|
|
|
|
clippy-subtree-update
|
|
|
|
clippy-subtree-update
|
|
|
|
This lint checks for code that looks like
```rust
let something : Vec<_> = (0..100).map(|_| {
1 + 2 + 3
}).collect();
```
which is more clear as
```rust
let something : Vec<_> = std::iter::repeat_with(|| {
1 + 2 + 3
}).take(100).collect();
```
or
```rust
let something : Vec<_> =
std::iter::repeat_n(1 + 2 + 3, 100)
.collect();
```
That is, a map over a range which does nothing with the parameter
passed to it is simply a function (or closure) being called `n`
times and could be more semantically expressed using `take`.
|
|
|
|
|
