Commit Graph

19941 Commits

Author SHA1 Message Date
Jacherr
e186ed2ad1 check return type of get and indexing 2024-05-30 11:45:57 +00:00
Jacherr
46b3264131 add backticks to doc comments 2024-05-30 11:45:43 +00:00
Jacherr
93b39d8910 disable indexing_slicing for custom Index impls 2024-05-30 11:45:43 +00:00
bors
03654badfd Auto merge of #12864 - tesuji:non-no-effect, r=y21
ignore array from `deref_addrof` lint

Split from https://github.com/rust-lang/rust-clippy/pull/12854

changelog: ignore array from `deref_addrof` lint

r? y21
2024-05-30 10:16:50 +00:00
bors
c9139bd546 Auto merge of #12867 - flip1995:rustup, r=flip1995
Rustup

r? `@ghost`

changelog: none
2024-05-30 08:11:24 +00:00
Philipp Krones
280ed2b594
Bump nightly version -> 2024-05-30 2024-05-30 09:44:33 +02:00
Philipp Krones
89037ea18f
Merge remote-tracking branch 'upstream/master' into rustup 2024-05-30 09:44:14 +02:00
Lzu Tao
8bd2a17dfe ignore array from deref_addrof lint
Note that semantics of repeat expr in array are the same
2024-05-30 08:34:44 +07:00
bors
bda7427621 Auto merge of #125360 - RalfJung:packed-field-reorder, r=fmease
don't inhibit random field reordering on repr(packed(1))

`inhibit_struct_field_reordering_opt` being false means we exclude this type from random field shuffling. However, `packed(1)` types can still be shuffled! The logic was added in https://github.com/rust-lang/rust/pull/48528 since it's pointless to reorder fields in packed(1) types (there's no padding that could be saved) -- but that shouldn't inhibit `-Zrandomize-layout` (which did not exist at the time).

We could add an optimization elsewhere to not bother sorting the fields for `repr(packed)` types, but I don't think that's worth the effort.

This *does* change the behavior in that we may now reorder fields of `packed(1)` structs (e.g. if there are niches, we'll try to move them to the start/end, according to `NicheBias`).  We were always allowed to do that but so far we didn't. Quoting the [reference](https://doc.rust-lang.org/reference/type-layout.html):

> On their own, align and packed do not provide guarantees about the order of fields in the layout of a struct or the layout of an enum variant, although they may be combined with representations (such as C) which do provide such guarantees.
2024-05-29 11:57:13 +00:00
J-ZhengLi
db30f6ce9f fix [redundant_closure] suggesting incorrect code with F: Fn() 2024-05-29 16:21:59 +08:00
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 (06bc4fc671, *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