Commit graph

20637 commits

Author SHA1 Message Date
Lzu Tao
4dcab72c1c add test for *&[a, b,...]` 2024-05-29 02:20:49 +00:00
Oli Scherer
e3e27ba3dd Create const block DefIds in typeck instead of ast lowering 2024-05-28 13:38:43 +00:00
bors
da4b2127c0 Auto merge of #12859 - cookie-s:dedup-single-char-name-diag, r=Alexendoo
[`many_single_char_names`]: Deduplicate diagnostics

Relates to #12379

Fix `many_single_char_names` lint so that it doesn't emit diagnostics when the current level of the scope doesn't contain any single character name.

```rust
let (a, b, c, d): (i32, i32, i32, i32);
match 1 {
  1 => (),
  e => {},
}
```
produced the exact same MANY_SINGLE_CHAR_NAMES diagnostic at each of the Arm `e => {}` and the Block `{}`.

---

changelog: [`many_single_char_names`]: Fix duplicate diagnostics
2024-05-28 12:41:14 +00:00
bors
76eee82e79 Auto merge of #12823 - schvv31n:fix-iter-on-empty-collections, r=y21
Suppress `iter_on_empty_collections` if the iterator's concrete type is relied upon

changelog: fixed #12807
2024-05-27 16:18:41 +00:00
bors
7e4c1ae0b6 Auto merge of #12843 - mdm:fix-unnecessary-to-owned-println-interaction, r=y21
Fix `unnecessary_to_owned` interaction with macro expansion

fixes #12821

In the case of an unnecessary `.iter().cloned()`, the lint `unnecessary_to_owned` might suggest to remove the `&` from references without checking if such references are inside a macro expansion. This can lead to unexpected behavior or even broken code if the lint suggestion is applied blindly. See issue #12821 for an example.

This PR checks if such references are inside macro expansions and skips this part of the lint suggestion in these cases.

changelog: [`unnecessary_to_owned`]: Don't suggest to remove `&` inside macro expansion
2024-05-27 14:26:50 +00:00
Guillaume Gomez
566dfd9008 Add needless_character_iteration lint 2024-05-27 14:16:02 +02:00
bors
20f0f135ee Auto merge of #12852 - finga:master, r=flip1995
book: Fix example code

Fix example code of the "Disabling evaluation of certain code" section in the configuration chapter.

changelog: none
2024-05-27 10:18:10 +00:00
Marc Dominik Migge
4a64180dd5 unnecessary_to_owned should not suggest to remove & in macro expansion 2024-05-27 12:05:18 +02:00
bors
4dd07f4e4e Auto merge of #125410 - fmease:adj-lint-diag-api, r=nnethercote
[perf] Delay the construction of early lint diag structs

Attacks some of the perf regressions from https://github.com/rust-lang/rust/pull/124417#issuecomment-2123700666.

See individual commits for details. The first three commits are not strictly necessary.
However, the 2nd one (06bc4fc67145e3a7be9b5a2cf2b5968cef36e587, *Remove `LintDiagnostic::msg`*) makes the main change way nicer to implement.
It's also pretty sweet on its own if I may say so myself.
2024-05-27 08:44:12 +00:00
bors
722de3b546 Auto merge of #12842 - J-ZhengLi:issue12801, r=y21
add parentheses to [`let_and_return`]'s suggestion

closes: #12801

---

changelog: suggest adding parentheses when linting [`let_and_return`] and [`needless_return`]
2024-05-27 08:04:36 +00:00
bors
8f23de1f4a Auto merge of #125468 - BoxyUwU:remove_defid_from_regionparam, r=compiler-errors
Remove `DefId` from `EarlyParamRegion`

Currently we represent usages of `Region` parameters via the `ReEarlyParam` or `ReLateParam` variants. The `ReEarlyParam` is effectively equivalent to `TyKind::Param` and `ConstKind::Param` (i.e. it stores a `Symbol` and a `u32` index) however it also stores a `DefId` for the definition of the lifetime parameter.

This was used in roughly two places:
- Borrowck diagnostics instead of threading the appropriate `body_id` down to relevant locations. Interestingly there were already some places that had to pass down a `DefId` manually.
- Some opaque type checking logic was using the `DefId` field to track captured lifetimes

I've split this PR up into a commit for generate rote changes to diagnostics code to pass around a `DefId` manually everywhere, and another commit for the opaque type related changes which likely require more careful review as they might change the semantics of lints/errors.

Instead of manually passing the `DefId` around everywhere I previously tried to bundle it in with `TypeErrCtxt` but ran into issues with some call sites of `infcx.err_ctxt` being unable to provide a `DefId`, particularly places involved with trait solving and normalization. It might be worth investigating adding some new wrapper type to pass this around everywhere but I think this might be acceptable for now.

This pr also has the effect of reducing the size of `EarlyParamRegion` from 16 bytes -> 8 bytes. I wouldn't expect this to have any direct performance improvement however, other variants of `RegionKind` over `8` bytes are all because they contain a `BoundRegionKind` which is, as far as I know, mostly there for diagnostics. If we're ever able to remove this it would shrink the `RegionKind` type from `24` bytes to `12` (and with clever bit packing we might be able to get it to `8` bytes). I am curious what the performance impact would be of removing interning of `Region`'s if we ever manage to shrink `RegionKind` that much.

Sidenote: by removing the `DefId` the `Debug` output for `Region` has gotten significantly nicer. As an example see this opaque type debug print before vs after this PR:
`Opaque(DefId(0:13 ~ impl_trait_captures[aeb9]::foo::{opaque#0}), [DefId(0:9 ~ impl_trait_captures[aeb9]::foo::'a)_'a/#0, T, DefId(0:9 ~ impl_trait_captures[aeb9]::foo::'a)_'a/#0])`
`Opaque(DefId(0:13 ~ impl_trait_captures[aeb9]::foo::{opaque#0}), ['a/#0, T, 'a/#0])`

r? `@compiler-errors` (I would like someone who understands the opaque type setup to atleast review the type system commit, but the rest is likely reviewable by anyone)
2024-05-27 06:36:57 +00:00
J-ZhengLi
03306b6ab6 suggest adding parentheses when linting [let_and_return] and [needless_return] 2024-05-27 11:49:10 +08:00
cookie-s
7110f471d3
[many_single_char_names]: Deduplicate diagnostics 2024-05-26 22:56:23 -04:00
WeiTheShinobi
c53cea90ad fix: let non_canonical_impls skip proc marco 2024-05-26 18:59:40 +08:00
finga
e61288cbf0 book: Fix example code
Fix example code of the "Disabling evaluation of certain code" section
in the configuration chapter.
2024-05-25 21:36:49 +02:00
bors
5aae5f6ae6 Auto merge of #12740 - lrh2000:sig-drop, r=blyxyas
`significant_drop_in_scrutinee`: Trigger lint only if lifetime allows early significant drop

I want to argue that the following code snippet should not trigger `significant_drop_in_scrutinee` (https://github.com/rust-lang/rust-clippy/issues/8987). The iterator holds a reference to the locked data, so it is expected that the mutex guard must be alive until the entire loop is finished.
```rust
use std::sync::Mutex;

fn main() {
    let mutex_vec = Mutex::new(vec![1, 2, 3]);
    for number in mutex_vec.lock().unwrap().iter() {
        dbg!(number);
    }
}
```

However, the lint should be triggered when we clone the vector. In this case, the iterator does not hold any reference to the locked data.
```diff
-     for number in mutex_vec.lock().unwrap().iter() {
+     for number in mutex_vec.lock().unwrap().clone().iter() {
```

Unfortunately, it seems that regions on the types of local variables are mostly erased (`ReErased`) in the late lint pass. So it is hard to tell if the final expression has a lifetime relevant to the value with a significant drop.

In this PR, I try to make a best-effort guess based on the function signatures. To avoid false positives, no lint is issued if the result is uncertain. I'm not sure if this is acceptable or not, so any comments are welcome.

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

changelog: [`significant_drop_in_scrutinee`]: Trigger lint only if lifetime allows early significant drop.

r? `@flip1995`
2024-05-25 13:11:21 +00:00
bors
5d10538fb4 Auto merge of #12809 - GuillaumeGomez:missing-backticks-fix, r=y21
Correctly handle closing parens in `missing_backticks` doc lint

Fixes #12795.

changelog: Correctly handle closing parens in `doc_markdown` lint
2024-05-25 12:03:07 +00:00
cookie-s
b6350e94f7
[nonminimal_bool]: Remove NotSimplificationVisitor 2024-05-24 22:30:24 -04:00
cookie-s
93a77f2812
[nonminimal_bool]: Deduplicate diagnostics 2024-05-24 20:27:12 -04:00
bors
674c641ecf Auto merge of #12836 - hamirmahal:feat/quick-fix-for-bare-urls, r=y21
feat: `Quick Fix` for `bare URLs`

closes #12835.

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

changelog: [`clippy::doc_markdown`]: `Quick Fix` for `bare URLs`
2024-05-24 21:51:45 +00:00
Hamir Mahal
17cc0a3a7d
feat: auto-fix for bare URLs in doc comments 2024-05-24 14:30:42 -07:00
Alex Macleod
95b295d976 Fix to_string_in_format_args with macro call receiver 2024-05-24 19:27:39 +00:00
Boxy
714e172ef2 Remove DefId from EarlyParamRegion (clippy/smir) 2024-05-24 18:06:57 +01:00
bors
f16317e9cc Auto merge of #12841 - B14CK313:fix-expect-derive, r=y21
fulfill expectations in `check_partial_eq_without_eq`

This is a followup to #12804, fixing a similar issue for `derive_partial_eq_without_eq` by using `span_lint_hir_and_then` instead of `span_lint_and_sugg`.

Additionally tests for both `#[allow(clippy::derive_partial_eq_without_eq)]` and `#[expect(clippy::derive_partial_eq_without_eq)]` are added.

changelog:[`derive_partial_eq_without_eq`]: fulfill expectations
2024-05-24 14:10:53 +00:00
bors
67b7b6a607 Auto merge of #12838 - kpreid:restriction-doc, r=llogiq
For restriction lints, replace “Why is this bad?” with “Why restrict this?”

The `restriction` group contains many lints which are not about necessarily “bad” things, but style choices — perhaps even style choices which contradict conventional Rust style — or are otherwise very situational. This results in silly wording like “Why is this bad? It isn't, but ...”, which I’ve seen confuse and distress a newcomer at least once.

To improve this situation, this PR replaces the “Why is this bad?” section heading with “Why restrict this?”, for most, but not all, restriction lints. I left alone the ones whose placement in the restriction group is more incidental.

In order to make this make sense, I had to remove the “It isn't, but” texts from the contents of the sections. Sometimes further changes were needed, or there were obvious fixes to make, and I went ahead and made those changes without attempting to split them into another commit, even though many of them are not strictly necessary for the “Why restrict this?” project; it seemed to me that it was more valuable to grab the low-hanging fruit than to be careful about it.

changelog: rephrased the documentation of `restriction` lints for clarity about their nature
2024-05-24 12:58:25 +00:00
Jakob Schwarz
7f30b20b28
fulfill expectations in check_partial_eq_without_eq
changelog: fulfill expectations in [derive_partial_eq_without_eq]
2024-05-24 08:44:41 +02:00
Kevin Reid
0f5338cd90 For restriction lints, replace “Why is this bad?” with “Why restrict this?”
The `restriction` group contains many lints which are not about
necessarily “bad” things, but style choices — perhaps even style choices
which contradict conventional Rust style — or are otherwise very
situational. This results in silly wording like “Why is this bad?
It isn't, but ...”, which I’ve seen confuse a newcomer at least once.

To improve this situation, this commit replaces the “Why is this bad?”
section heading with “Why restrict this?”, for most, but not all,
restriction lints. I left alone the ones whose placement in the
restriction group is more incidental.

In order to make this make sense, I had to remove the “It isn't, but”
texts from the contents of the sections. Sometimes further changes
were needed, or there were obvious fixes to make, and I went ahead
and made those changes without attempting to split them into another
commit, even though many of them are not strictly necessary for the
“Why restrict this?” project.
2024-05-23 15:51:33 -07:00
bors
76856ffb57 Auto merge of #12833 - kpreid:empty-enum-doc, r=Manishearth
Rephrase and expand `empty_enum` documentation.

* Remove incorrect claim that “wrappers around it are the conventional way to define an uninhabited type”.
* Discuss why one would use `!`, a newtype struct, or keep the enum.
* Add links to relevant documentation.

Before writing this change, I asked the community via [IRLO](https://internals.rust-lang.org/t/idiomatic-definition-of-uninhabited-never-newtypes/20877) and [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Never.20type.20wrappers.20.2F.20defining.20uninhabited.20newtypes) for feedback. The broad consensus seemed to me to be that in a world where both `never_type` and `min_exhaustive_patterns` are stable and therefore available for general use, we _might_ want to `!` or newtypes of it — but it's certainly not “conventional” _yet._ Therefore, I've removed “conventional” and added a discussion of the pros and cons of different choices.

changelog: [`empty_enum`]: expanded documentation
2024-05-23 16:19:15 +00:00
León Orell Valerian Liehr
0c653d9f91 Remove LintDiagnostic::msg
* instead simply set the primary message inside the lint decorator functions
* it used to be this way before [#]101986 which introduced `msg` to prevent
  good path delayed bugs (which no longer exist) from firing under certain
  circumstances when lints were suppressed / silenced
* this is no longer necessary for various reasons I presume
* it shaves off complexity and makes further changes easier to implement
2024-05-23 04:08:35 +02:00
Kevin Reid
cfa150b0dd Rephrase and expand empty_enum documentation.
* Remove incorrect claim that “wrappers around it are the conventional
  way to define an uninhabited type”.
* Discuss why one would use `!`, a newtype struct, or keep the enum.
* Add links to relevant documentation.
2024-05-22 18:03:18 -07:00
Ruihan Li
6641f9f6e1 Track lifetime on values with significant drop 2024-05-23 00:37:02 +08:00
bors
05c4053628 Auto merge of #12398 - WeiTheShinobi:bug-lint-numbered_fields, r=Manishearth
bug fix: lint numbered_fields message error

fixes #12367

changelog: [`numbered_fields`]: fix macro expand message error.
2024-05-22 15:50:46 +00:00
Vadim Petrochenkov
765baba165 rustc: Use tcx.used_crates(()) more
And explain when it should be used.
2024-05-22 18:02:51 +03:00
WeiTheShinobi
038f6179d7 bug fix: lint numbered_fields message error 2024-05-22 15:26:32 +08:00
schvv31n
7439ecb07c Added check for type unification with the iter 2024-05-21 22:21:33 +01:00
bors
ea535c97d5 Auto merge of #12804 - B14CK313:master, r=y21
fulfill expectations in `check_unsafe_derive_deserialize`

The utility function `clippy_utils::fulfill_or_allowed` is not used because using it would require to move the check for allowed after the check iterating over all inherent impls of the type, doing possibly unnecessary work.
Instead, `is_lint_allowed` is called as before, but additionally, once certain that the lint should be emitted, `span_lint_hir_and_then` is called instead of `span_lint_and_help` to also fulfill expectations.

Note: as this is my first contribution, please feel free to nitpick or request changes. I am happy to adjust the implementation.

fixes: #12802

changelog: fulfill expectations in [`unsafe_derive_deserialize`]
2024-05-21 19:05:36 +00:00
Philipp Krones
4363278c73 Merge commit '2efebd2f0c03dabbe5c3ad7b4ebfbd99238d1fb2' into clippy-subtree-update 2024-05-21 10:39:30 -07:00
Ralf Jung
a14ca6005c don't inhibit random field reordering on repr(packed(1)) 2024-05-21 19:22:04 +02:00
Guillaume Gomez
4f98cc6d55 Correctly handle closing parens in missing_backticks doc lint 2024-05-21 14:55:30 +02:00
bors
2efebd2f0c Auto merge of #12765 - yusufraji:while-float, r=llogiq
Add new lint `while_float`

This PR adds a nursery lint that checks for while loops comparing floating point values.

changelog:
```
changelog: [`while_float`]: Checks for while loops comparing floating point values.
```

Fixes #758
2024-05-21 11:36:31 +00:00
Michael Goulet
ca1337a7bc Remove a clippy test that doesn't apply anymore 2024-05-20 19:21:38 -04:00
schvv31n
b31625cdc7 Accounted for possible extra layers before the consuming parent expr 2024-05-20 21:27:30 +01:00
Alex Macleod
9e5523e8c4 lint_groups_priority: ignore lints & groups at the same level 2024-05-20 19:44:55 +00:00
Matthias Krüger
acf38f8466 Rollup merge of #125173 - scottmcm:never-checked, r=davidtwco
Remove `Rvalue::CheckedBinaryOp`

Zulip conversation: <https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/intrinsics.20vs.20binop.2Funop/near/438729996>
cc `@RalfJung`

While it's a draft,
r? ghost
2024-05-20 18:13:48 +02:00
schvv31n
3955bd4c98 fixed formatting 2024-05-20 08:07:48 +01:00
schvv31n
3629372723 Lint on closure calls, suppress on callable constants calls 2024-05-20 08:05:49 +01:00
bors
298f38c06e Auto merge of #125294 - matthiaskrgr:rollup-w42c829, r=matthiaskrgr
Rollup of 4 pull requests

Successful merges:

 - #124948 (chore: Remove repeated words (extension of #124924))
 - #124992 (Add example to IsTerminal::is_terminal)
 - #125279 (make `Debug` impl for `Term` simpler)
 - #125286 (Miri subtree update)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-05-19 21:30:43 +00:00
Matthias Krüger
647f222885 Rollup merge of #124948 - blyxyas:remove-repeated-words, r=compiler-errors
chore: Remove repeated words (extension of #124924)

When I saw #124924 I thought "Hey, I'm sure that there are far more than just two typos of this nature in the codebase". So here's some more typo-fixing.

Some found with regex, some found with a spellchecker. Every single one manually reviewed by me (along with hundreds of false negatives by the tools)
2024-05-19 22:50:55 +02:00
schvv31n
9d311b5c2b initial fix 2024-05-19 21:41:13 +01:00
Alex Macleod
68e7356b7e Switch to for_each_expr in some lints 2024-05-19 16:47:02 +00:00