Commit graph

7239 commits

Author SHA1 Message Date
J-ZhengLi
91f3fad8e7 check for init expr when linting [question_mark] 2024-03-27 08:36:08 +08:00
bors
b8b9b27500 Auto merge of #12555 - GuillaumeGomez:duplicated_attribute, r=blyxyas
Don't emit `duplicated_attribute` lint on "complex" `cfg`s

Part of #12537.

changelog: Don't emit `duplicated_attribute` lint on "complex" `cfg`s
2024-03-26 15:12:23 +00:00
Guillaume Gomez
e3f3a4b7dc Don't emit duplicated_attribute lint on "complex" cfgs 2024-03-26 14:28:32 +01:00
Quinn Sinclair
9655231eb8 Allow filter_map_identity when the closure is typed
This extends the `filter_map_identity` lint to support typed closures.

For untyped closures, we know that the program compiles, and therefore
we can safely suggest using flatten.

For typed closures, they may participate in type resolution. In this case
we use `Applicability::MaybeIncorrect`.

Details:
https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Should.20.60filter_map_identity.60.20lint.20when.20closures.20are.20typed.3F
2024-03-25 23:40:30 +01:00
bors
b1b7352880 Auto merge of #12536 - samueltardieu:issue-12505, r=Manishearth
`manual_assert`: do not add extra semicolon

Fixes #12505

changelog: [`manual_assert`]: do not add extra semicolon to suggestion
2024-03-25 20:07:54 +00:00
y21
9e82ad87b9 [let_and_return]: avoid linting when #[cfg] attributes are present 2024-03-25 17:48:05 +00:00
granddaifuku
2a62200b8d fix: suspicious_else_formatting false positive when else is included in comments 2024-03-25 02:17:56 +09:00
Peter Jaszkowiak
f2e91ab1b9 match syms, remove lint_reasons 2024-03-24 10:16:45 -06:00
Jacob Kiesel
0cf9d9c440 restrict manual_clamp to const case, bring it out of nursery 2024-03-23 21:28:58 -06:00
bors
95c62ffae9 Auto merge of #12239 - GuillaumeGomez:missing_transmute_annotation, r=y21
Add `missing_transmute_annotations` lint

Fixes https://github.com/rust-lang/rust-clippy/issues/715.

r? `@blyxyas`

changelog: Add `missing_transmute_annotations` lint
2024-03-24 00:20:28 +00:00
Guillaume Gomez
ee2558223f Do no emit missing_transmute_annotations lint if the transmute is the only expr in the function 2024-03-24 00:50:28 +01:00
Guillaume Gomez
ffa12798c0 Correctly handle transmute as return value from block and let var: _ = transmute 2024-03-24 00:50:26 +01:00
Guillaume Gomez
8e0496170d Add ui test for missing_transmute_annotations 2024-03-24 00:47:59 +01:00
bors
12f7c17ae0 Auto merge of #12535 - samueltardieu:issue-12528, r=y21
`useless_asref`: do not lint `.as_ref().map(Arc::clone)`

This applies to `Arc`, `Rc`, and their weak variants. Using `.clone()` would be less idiomatic.

This follows the discussion in <https://github.com/rust-lang/rust-clippy/issues/12528#issuecomment-2014444305>.

changelog: [`useless_asref`]: do not lint `.as_ref().map(Arc::clone)` and similar
2024-03-23 10:46:18 +00:00
Samuel Tardieu
fed2f28223 Do not rewrite .as_ref().map(Arc::clone) and similar 2024-03-23 09:59:14 +01:00
bors
db416211d6 Auto merge of #12486 - J-ZhengLi:issue12435, r=y21
don't lint [`mixed_attributes_style`] when mixing docs and other attrs

fixes: #12435
fixes: #12436
fixes: #12530

---

changelog: don't lint [`mixed_attributes_style`] when mixing different kind of attrs; and move it to late pass;
2024-03-23 04:28:19 +00:00
J-ZhengLi
e9f25b3b09 add test cases for #12435
don't lint [`mixed_attributes_style`] when mixing docs and other attrs

add test files for issue #12436

move [`mixed_attributes_style`] to `LateLintPass` to enable global `allow`

stop [`mixed_attributes_style`] from linting on different attributes

add `@compile-flags` to [`mixed_attributes_style`]'s test;

turns out not linting in test mod is not a FN.

Apply suggestions from code review

Co-authored-by: Timo <30553356+y21@users.noreply.github.com>

move [`mixed_attributes_style`] to late pass and stop it from linting on different kind of attributes
2024-03-23 12:13:39 +08:00
Samuel Tardieu
c137c78ba2 manual_assert: do not add extra semicolon 2024-03-23 01:32:25 +01:00
bors
c7bb200054 Auto merge of #12532 - samueltardieu:issue-12531, r=llogiq
Add necessary parentheses to `manual_unwrap_or_default` lint output

Fix #12531

----

changelog: [`manual_unwrap_or_default`]: add parentheses to suggestion when appropriate
2024-03-22 19:53:26 +00:00
Matthias Krüger
1c37a23700 Rollup merge of #122195 - jieyouxu:impl-return-note, r=fmease
Note that the caller chooses a type for type param

```
error[E0308]: mismatched types
  --> $DIR/return-impl-trait.rs:23:5
   |
LL | fn other_bounds<T>() -> T
   |                 -       -
   |                 |       |
   |                 |       expected `T` because of return type
   |                 |       help: consider using an impl return type: `impl Trait`
   |                 expected this type parameter
...
LL |     ()
   |     ^^ expected type parameter `T`, found `()`
   |
   = note: expected type parameter `T`
                   found unit type `()`
   = note: the caller chooses the type of T which can be different from ()
```

Tried to see if "expected this type parameter" can be replaced, but that goes all the way to `rustc_infer` so seems not worth the effort and can affect other diagnostics.

Revives #112088 and #104755.
2024-03-22 20:31:28 +01:00
bors
52b2a5e50d Auto merge of #12529 - samueltardieu:issue-12528, r=y21
Do not warn on .map(_::clone) for Arc, Rc, and their weak variants

Those constructions are idiomatic, and using `Arc::clone(x)` and `Rc::clone(x)` is often the recommended way of cloning a `Arc` or a `Rc`.

Fix #12528

changelog: [`map_clone`]: do not warn on `.map(_::clone)` for `Arc`, `Rc`, and their `Weak` variants
2024-03-22 15:11:52 +00:00
Samuel Tardieu
2ffd1336c7 Add necessary parentheses to manual_unwrap_or_default lint output 2024-03-22 15:42:55 +01:00
bors
f2020c884f Auto merge of #12508 - y21:issue12506, r=llogiq
Fix infinite loop in `cast_sign_loss` when peeling unwrap method calls

Fixes #12506

The lint wants to peel method calls but didn't actually reassign the expression, leading to an infinite loop.

----

changelog: Fix infinite loop in [`cast_sign_loss`] when having two chained `.unwrap()` calls
2024-03-22 13:19:09 +00:00
Samuel Tardieu
7c9fe30ce4 Do not warn on .map(_::clone) for Arc, Rc, and their weak variants
Those constructions are idiomatic, and using `Arc::clone(x)` and
`Rc::clone(x)` is often the recommended way of cloning a `Arc` or a
`Rc`.
2024-03-22 10:02:09 +01:00
León Orell Valerian Liehr
b7026f87f5 Update (doc) comments
Several (doc) comments were super outdated or didn't provide enough context.

Some doc comments shoved everything in a single paragraph without respecting
the fact that the first paragraph should be a single sentence because rustdoc
treats these as item descriptions / synopses on module pages.
2024-03-22 06:31:51 +01:00
Catherine
0c392d918a new lint legacy_numeric_constants 2024-03-21 17:10:02 -06:00
Philipp Krones
0e62b18435 Merge commit '9d6f41691ed9dbfaec2a2df2661c42451f2fe0d3' into clippy-subtree-update 2024-03-21 22:20:40 +01:00
Philipp Krones
7d42d736c5
Merge remote-tracking branch 'upstream/master' into rustup 2024-03-21 22:05:29 +01:00
bors
34766a6792 Auto merge of #12496 - Jacherr:issue-12492, r=blyxyas
Disable `cast_lossless` when casting to u128 from any (u)int type

Fixes https://github.com/rust-lang/rust-clippy/issues/12492

Disables `cast_lossless` when casting to u128 from any int or uint type. The lint states that when casting to any int type, there can potentially be lossy behaviour if the source type ever exceeds the size of the destination type in the future, which is impossible with a destination of u128.

It's possible this is a bit of a niche edge case which is better addressed by just disabling the lint in code, but I personally couldn't think of any good reason to still lint in this specific case - maybe except if the source is a bool, for readability reasons :).

changelog: FP: `cast_lossless`: disable lint when casting to u128 from any (u)int type
2024-03-20 23:08:45 +00:00
humannum14916
db7c9feaa0 Add UI test for new MSRV check 2024-03-20 14:07:53 -04:00
bendn
22f57ff584 fix for x in y unsafe { } 2024-03-20 23:33:16 +07:00
Jacherr
477108d382 FP: cast_lossless: disable lint when casting to (u)128 from any (u)int type 2024-03-20 13:20:51 +00:00
humannum14916
8c866d36cc Add test for MSRV checking for assigning_clones 2024-03-19 17:07:27 -04:00
y21
3930f8b45d fix infinite loop when peeling unwrap method calls 2024-03-19 00:13:18 +01:00
Esteban Küber
8339474a7c When displaying multispans, ignore empty lines adjacent to ...
```
error[E0308]: `match` arms have incompatible types
   --> tests/ui/codemap_tests/huge_multispan_highlight.rs:98:18
    |
6   |       let _ = match true {
    |               ---------- `match` arms have incompatible types
7   |           true => (
    |  _________________-
8   | |             // last line shown in multispan header
...   |
96  | |
97  | |         ),
    | |_________- this is found to be of type `()`
98  |           false => "
    |  __________________^
...   |
119 | |
120 | |         ",
    | |_________^ expected `()`, found `&str`

error[E0308]: `match` arms have incompatible types
   --> tests/ui/codemap_tests/huge_multispan_highlight.rs:215:18
    |
122 |       let _ = match true {
    |               ---------- `match` arms have incompatible types
123 |           true => (
    |  _________________-
124 | |
125 | |         1 // last line shown in multispan header
...   |
213 | |
214 | |         ),
    | |_________- this is found to be of type `{integer}`
215 |           false => "
    |  __________________^
216 | |
217 | |
218 | |         1 last line shown in multispan
...   |
237 | |
238 | |         ",
    | |_________^ expected integer, found `&str`
```
2024-03-18 16:25:36 +00:00
bors
b5dcaae844 Auto merge of #12498 - y21:issue12489, r=blyxyas
[`map_entry`]: call the visitor on the local's `else` block

Fixes #12489

The lint already has all the logic it needs for figuring out if it can or can't suggest a closure if it sees control flow expressions like `break` or `continue`, but it was ignoring the local's else block, which meant that it didn't see the `return None;` in a `let..else`.

changelog: [`map_entry`]: suggest `if let` instead of a closure when `return` expressions exist in the else block of a `let..else`
2024-03-18 06:28:47 +00:00
bors
e9a50f2859 Auto merge of #12451 - Jacherr:issue-12391, r=llogiq
new restriction lint: `integer_division_remainder_used`

Fixes https://github.com/rust-lang/rust-clippy/issues/12391

Introduces a restriction lint which disallows the use of `/` and `%` operators on any `Int` or `Uint` types (i.e., any that use the default `Div` or `Rem` trait implementations). Custom implementations of these traits are ignored.

----

changelog: Add new restriction lint [`integer_division_remainder_used`]
2024-03-17 08:10:32 +00:00
bors
d202eb653b Auto merge of #12450 - cookie-s:fix-optopt-duplicate-diags, r=llogiq
[`option_option`]: Fix duplicate diagnostics

Relates to #12379

This `option_option` lint change skips checks against `ty`s inside `field_def`s defined by external macro to prevent duplicate diagnostics to the same span `ty` by multiple `Struct` definitions.

---

changelog: [`option_option`]: Fix duplicate diagnostics
2024-03-17 07:51:49 +00:00
bors
67fa36a9f2 Auto merge of #12479 - y21:readonly_write_lock_perf, r=Jarcho
move `readonly_write_lock` to perf

[There haven't been any issues](https://github.com/rust-lang/rust-clippy/issues?q=is%3Aissue+readonly_write_lock) since its creation and it's a pretty useful lint I think, so I'd say it's worth giving it a try?

Did a lintcheck run on 300 crates with no results, but I guess `RwLock` is usually not something that's used much in libraries.

changelog: move [`readonly_write_lock`] to perf (now warn-by-default)
2024-03-17 03:35:17 +00:00
bors
12ecaa8367 Auto merge of #12482 - J-ZhengLi:issue12131, r=Jarcho
fix [`dbg_macro`] FN when dbg is inside some complex macros

fixes: #12131

It appears that [`root_macro_call_first_node`] only detects `println!` in the following example:
```rust
println!("{:?}", dbg!(s));
```
---

changelog: fix [`dbg_macro`] FN when `dbg` is inside some complex macros

(re-opening b'cuz bors doesn't like my previous one)
2024-03-17 03:22:20 +00:00
许杰友 Jieyou Xu (Joe)
f9a9c4bf3b Note that type param is chosen by caller when suggesting return impl Trait 2024-03-16 23:20:42 +00:00
bors
59a5ad4840 Auto merge of #12441 - CBSpeir:dedup-else-if-without-else, r=dswij
[`else_if_without_else`]: Fix duplicate diagnostics

Relates to: #12379

changelog:  Fix duplicate lint diagnostic emission from [`else_if_without_else`]
2024-03-16 15:55:11 +00:00
y21
4e72ca31b5 [map_entry]: call the visitor on the local's else block 2024-03-16 14:15:45 +01:00
bors
c9f24827b3 Auto merge of #12493 - y21:issue12491, r=Alexendoo
fix span calculation for non-ascii in `needless_return`

Fixes #12491

Probably fixes #12328 as well, but that one has no reproducer, so 🤷

The bug was that the lint used `rfind()` for finding the byte index of the start of the previous non-whitespace character:
```
// abc\n     return;
     ^
```
... then subtracting one to get the byte index of the actual whitespace (the `\n` here).
(Subtracting instead of adding because it treats this as the length from the `return` token to the `\n`)

That's correct for ascii, like here, and will get us to the `\n`, however for non ascii, the `c` could be multiple bytes wide, which would put us in the middle of a codepoint if we simply subtract 1 and is what caused the ICE.

There's probably a lot of ways we could fix this.
This PR changes it to iterate backwards using bytes instead of characters, so that when `rposition()` finally finds a non-whitespace byte, we *know* that we've skipped exactly 1 byte. This was *probably*(?) what the code was intending to do

changelog: Fix ICE in [`needless_return`] when previous line end in a non-ascii character
2024-03-15 17:30:23 +00:00
y21
d3f8f3e9d7 fix span calculation for non-ascii in needless_return 2024-03-15 16:59:23 +01:00
bors
5a11fefc25 Auto merge of #12432 - Ethiraric:fix-12411, r=y21
[`unused_enumerate_index`]: trigger on method calls

The lint used to check for patterns looking like:
```rs
for (_, x) in some_iter.enumerate() {
    // Index is ignored
}
```

This commit further checks for chained method calls constructs where we
can detect that the index is unused. Currently, this checks only for the
following patterns:
```rs
some_iter.enumerate().map_function(|(_, x)| ..)
let x = some_iter.enumerate();
x.map_function(|(_, x)| ..)
```
where `map_function` is one of `all`, `any`, `filter_map`, `find_map`,
`flat_map`, `for_each` or `map`.

Fixes #12411.

*Please write a short comment explaining your change (or "none" for internal only changes)*

changelog: [`unused_enumerate_index`]: add detection for method chains such as `iter.enumerate().map(|(_, x)| x)`
2024-03-14 22:26:06 +00:00
Ethiraric
dadcd94b2a [unused_enumerate_index]: Keep explicit element type
Prior to this change, it might be that the lint would remove an explicit
type that was necessary for the type system to keep track of types.

This should be the last change that prevented this lint to be machine
applicable.
2024-03-14 23:12:47 +01:00
bors
b667d02340 Auto merge of #12472 - GuillaumeGomez:fix-10262, r=blyxyas
Don't emit `doc_markdown` lint for missing backticks if it's inside a quote

Fixes #10262.

changelog: Don't emit `doc_markdown` lint for missing backticks if it's inside a quote
2024-03-14 21:39:25 +00:00
bors
8a78128e9d Auto merge of #12386 - Ethiraric:fix-12381, r=blyxyas
[`use_self`]: Make it aware of lifetimes

Have the lint trigger even if `Self` has generic lifetime parameters.

```rs
impl<'a> Foo<'a> {
    type Item = Foo<'a>; // Can be replaced with Self

    fn new() -> Self {
        Foo { // No lifetime, but they are inferred to be that of Self
              // Can be replaced as well
            ...
        }
    }

    // Don't replace `Foo<'b>`, the lifetime is different!
    fn eq<'b>(self, other: Foo<'b>) -> bool {
        ..
    }
```

Fixes #12381

*Please write a short comment explaining your change (or "none" for internal only changes)*

changelog: [`use_self`]: Have the lint trigger even if `Self` has generic lifetime parameters
2024-03-14 16:28:57 +00:00
maekawatoshiki
c5d3b62cfc
Fix conflict 2024-03-14 12:40:33 +09:00