Commit graph

7909 commits

Author SHA1 Message Date
Kisaragi Marine
1661e7ee76
re-implement fix for rust-lang#11357 2023-11-27 23:43:39 +09:00
Samuel Tardieu
23d533264f Fix box_default behaviour with empty vec![] coming from macro arg 2023-11-26 18:40:50 +01:00
bors
3664d6328d Auto merge of #11864 - GuillaumeGomez:option_map_or_err_ok, r=flip1995
Create new lint `option_map_or_err_ok`

Fixes #10045.

For the following code:

```rust
let opt = Some(1);
opt.map_or(Err("error"), Ok);
```

It suggests to instead write:

```rust
let opt = Some(1);
opt.ok_or("error");
```

r? `@flip1995`

changelog: Create new lint `option_map_or_err_ok`
2023-11-25 11:35:46 +00:00
bors
6cfbe57075 Auto merge of #11862 - christophbeberweil:7125-single-element-loop-over-range, r=llogiq
suggest alternatives to iterate an array of ranges

works towards #7125
changelog: [`single_element_loop`]: suggest better syntax when iterating over an array of a single range

`@thinkerdreamer` and myself worked on this issue during a workshop by `@llogiq` at the RustLab 2023 conference. It is our first contribution to clippy.

When iterating over an array of only one element, _which is a range_, our change suggests to replace the array with the contained range itself. Additionally, a hint is printed stating that the user probably intended to iterate over the range and not the array. If the single element in the array is not a range, the previous suggestion in the form of `let {pat_snip} = {prefix}{arg_snip};{block_str}`is used.

This change lints the array with the single range directly, so any prefixes or suffixes are covered as well.
2023-11-24 17:15:33 +00:00
Guillaume Gomez
3a3773fa30 Add test for option_map_or_err_ok lint 2023-11-24 18:14:34 +01:00
Christoph Beberweil
f9c6335a0f feat: 7125 code snippets are wrapped in backticks 2023-11-24 17:47:31 +01:00
Christoph Beberweil
bce869f0c0 fix: 7125 lint message should start with a small letter 2023-11-24 17:29:03 +01:00
bors
e075823e2c Auto merge of #11850 - Nilstrieb:tbd, r=dswij
[`deprecated_semver`]: Allow `#[deprecated(since = "TBD")]`

"TBD" is allowed by rustdoc, saying that it will be deprecated in a future version. rustc will also not actually warn on it.
I found this while checking the rust-lang/rust with clippy.

changelog: [`deprecated_semver`]: allow using `since = "TBD"`
2023-11-24 14:46:50 +00:00
bors
96eab0655f Auto merge of #11859 - y21:issue11856, r=blyxyas
[`missing_asserts_for_indexing`]: work with bodies instead of blocks separately

Fixes #11856

Before this change, this lint would check blocks independently of each other, which means that it misses `assert!()`s from parent blocks.
```rs
// check_block
assert!(x.len() > 1);

{
  // check_block
  // no assert here
  let _ = x[0] + x[1];
}
```

This PR changes it to work with bodies rather than individual blocks. That means that a function will be checked in one go and we can remember if an `assert!` occurred anywhere.

Eventually it would be nice to have a more control flow-aware analysis, possibly by rewriting it as a MIR lint, but that's more complicated and I wanted this fixed first.

changelog: [`missing_asserts_for_indexing`]: accept `assert!`s from parent blocks
2023-11-24 12:18:11 +00:00
Christoph Beberweil
2512341fe4 feat: 7125 shorten lint text 2023-11-24 10:38:45 +01:00
Christoph Beberweil
447edf92b4 suggest alternatives to iterate an array of ranges
Co-authored-by: ThinkerDreamer <74881094+ThinkerDreamer@users.noreply.github.com>
2023-11-23 23:07:36 +01:00
Guillaume Gomez
6c84b96886 Improve error messages format 2023-11-23 13:32:41 +01:00
Guillaume Gomez
5d330d08fb Add new test for result_map_or_into_option extension 2023-11-23 10:57:37 +01:00
y21
553857bb2b check on a per-body level instead of blocks independently 2023-11-23 09:31:49 +01:00
bors
c24784ed81 Auto merge of #11757 - matthri:iter-kv-map-msrv-fix, r=Alexendoo
Fix iter_kv_map false positive into_keys and into_values suggestion

fixes: #11752

changelog: [`iter_kv_map`]: fix false positive: Don't suggest `into_keys()` and `into_values()` if the MSRV is to low
2023-11-22 20:39:44 +00:00
bors
a72730e9a1 Auto merge of #11844 - GuillaumeGomez:manual_non_exhaustive-rm-underscore-check, r=flip1995
Remove underscore check for `manual_non_exhaustive` lint

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

As indicated in https://github.com/rust-lang/rust-clippy/pull/10559, the underscore check should be removed.

changelog: remove underscore check for `manual_non_exhaustive` lint

r? `@blyxyas`
2023-11-22 13:37:31 +00:00
Guillaume Gomez
91fc4b3001 Remove underscore check for manual_non_exhaustive lint 2023-11-22 13:42:13 +01:00
bors
b21c9d4d31 Auto merge of #11849 - GuillaumeGomez:add-more-transmute_ref_to_ref-tests, r=blyxyas
Add tests for issues #10285, #10286, #10289, #10287

Fixes #10285.
Fixes #10286.
Fixes #10289.
Fixes #10287.

This PR simply adds tests for the listed issues as they're already implemented so we can close them.

r? `@blyxyas`

changelog:none
2023-11-22 11:29:13 +00:00
bors
a8b0e5ffad Auto merge of #11627 - y21:issue11616, r=giraffate
[`needless_return_with_question_mark`]: don't lint if never type is used for coercion

Fixes #11616

When we have something like
```rs
let _x: String = {
  return Err(())?;
};
```
we shouldn't suggest removing the `return` because the `!`-ness of `return` is used to coerce the enclosing block to some other type. That will lead to a typeck error without a diverging expression like `return`.

changelog: [`needless_return_with_question_mark`]: don't lint if `return`s never typed-ness is used for coercion
2023-11-22 04:49:00 +00:00
Nilstrieb
43d8d51b6d Allow #[deprecated(since = "TBD")]
"TBD" is allowed by rustdoc, saying that it will be deprecated in a future version.
rustc will also not actually warn on it.
2023-11-21 22:03:00 +01:00
Guillaume Gomez
2fa87fb93d Add tests for issues #10285, #10286, #10289, #10287 2023-11-21 14:04:19 +01:00
y21
a74fa97fab [needless_return_with_question_mark]: dont lint in case of coercion 2023-11-21 12:02:12 +01:00
Guillaume Gomez
5cdda53e47 Add ui test for check_private_items config 2023-11-21 11:43:16 +01:00
Guillaume Gomez
abd9deb9f4 [missing_safety_doc], [unnecessary_safety_doc], [missing_panics_doc], [missing_errors_doc]: Added the [check-private-items] configuration to enable lints on private items.
[#11842](https://github.com/rust-lang/rust-clippy/pull/11842)
2023-11-21 11:42:42 +01:00
bors
72c0d80f46 Auto merge of #11801 - y21:split_doc_pass, r=blyxyas
Split `doc.rs` up into a subdirectory

So, first, sorry for the bad diff. 😅

In #11798, `@flip1995`  suggested splitting `doc.rs` up, much like how we have the `methods/`, `matches/`, `types/` subdirectories.
I agree with this, the file is getting bigger as we add more and more doc lints that it makes sense to do this refactoring.

This is purely an internal change that moves things around a bit.
(**EDIT:** depending on the outcome of https://github.com/rust-lang/rust-clippy/pull/11801#issuecomment-1816715615 , this may change the lint group name from `doc_markdoc` to `doc`).

I tried to not change any of the actual logic of the lints and as such some things weren't as easy to move to a separate file. So we still have some `span_lint*` calls in the `doc/mod.rs` file, which I think is fine. This is also the case in `methods/mod.rs`.

Also worth mentioning that the lints missing_errors_doc, missing_panics_doc, missing_safety_doc and unnecessary_safety_doc have a lot of the same logic so it didn't make much sense for each of these to be in their own file. Instead I just put them all in `missing_headers.rs`

I also added a bit of documentation to the involved `check_{attrs,doc}` methods.

changelog: none
2023-11-20 17:22:05 +00:00
ofeeg
34d9e88a47
New lint clippy::join_absolute_paths
* `join_absolute_paths` Address PR review
* Move `clippy::join_absolute_paths` to `clippy::suspicious`
* `join_absolute_paths`: Address PR review

Co-Authored-By: ofeeg <mhanna0000@gmail.com>
2023-11-20 13:28:28 +01:00
y21
56cee3c587 move doc.rs to its own subdirectory 2023-11-20 12:08:07 +01:00
bors
41140e3cb8 Auto merge of #11840 - GuillaumeGomez:improve-maybe_misused_cfg, r=blyxyas
Improve maybe misused cfg

Follow-up of the improvements that were suggested to me in https://github.com/rust-lang/rust-clippy/pull/11821:

 * I unified the output to use the same terms.
 * I updated the code to prevent creating a new symbol.

r? `@blyxyas`

changelog: [`maybe_misued_cfg`]: Output and code improvements
2023-11-19 22:31:11 +00:00
Guillaume Gomez
dfbca7ffa8 Improve maybe_misused_cfg lint output
Small performance improvement when comparing symbols for `maybe_misused_cfg`
Improve suggestion for `maybe_misused_cfg` lint
2023-11-19 22:46:19 +01:00
bors
9c3a365fd2 Auto merge of #11781 - partiallytyped:11710, r=xFrednet
Verify Borrow<T> semantics for types that implement Hash, Borrow<str> and Borrow<[u8]>.

Fixes #11710

The essence of the issue is that types that implement Borrow<T> provide a facet or a representation of the underlying type. Under these semantics `hash(a) == hash(a.borrow())`.

This is a problem when a type implements `Borrow<str>`, `Borrow<[u8]>` and Hash, it is expected that the hash of all three types is identical. The problem is that the hash of [u8] is not the same as that of a String, even when the byte reference ([u8]) is derived from `.as_bytes()`

- [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`

---

 - [x] Explanation of the issue in the code
 - [x] Tests reproducing the issue
 - [x] Lint rule and emission

---

changelog: New lint: [`impl_hash_borrow_with_str_and_bytes`]
[#11781](https://github.com/rust-lang/rust-clippy/pull/11781)
2023-11-19 10:59:34 +00:00
Quinn Sinclair
3c1e0afa58 New Lint [impl_hash_with_borrow_str_and_bytes]
Implements a lint to prevent implementation of Hash, Borrow<str> and
Borrow<[u8]> as it breaks Borrow<T> "semantics". According to the book,
types that implement Borrow<A> and Borrow<B> must ensure equality of
borrow results under Eq,Ord and Hash.

> In particular Eq, Ord and Hash must be equivalent for borrowed and
owned values: x.borrow() == y.borrow() should give the same result as x == y.

In the same way, hash(x) == hash(x as Borrow<[u8]>) != hash(x as Borrow<str>).

changelog: newlint [`impl_hash_with_borrow_str_and_bytes`]
2023-11-19 11:33:01 +01:00
bors
dbd19f9b48 Auto merge of #11691 - sjwang05:lines-filter-map-ok-fix, r=Centri3
Lint `flatten()` under `lines_filter_map_ok`

Fixes #11686

changelog: [`lines_filter_map_ok`]: Also lint calls to `flatten()`
2023-11-19 01:50:24 +00:00
bors
9263f806d8 Auto merge of #11782 - Alexendoo:macro-use-imports-ordering, r=Centri3
Make `macro_use_imports` lint ordering more stable

changelog: none

Fixes [the `macro_use_imports` ordering dependence](https://github.com/rust-lang/rust/pull/117649#issuecomment-1797716088) on the hash of `Span`s
2023-11-19 01:39:06 +00:00
bors
e8e9510219 Auto merge of #11002 - y21:issue9422, r=Jarcho
teach `eager_or_lazy` about panicky arithmetic operations

Fixes #9422
Fixes #9814
Fixes #11793

It's a bit sad that we have to do this because arithmetic operations seemed to me like the prime example where a closure would not be necessary, but this has "side effects" (changes behavior when going from lazy to eager) as some of these panic on overflow/underflow if compiled with `-Coverflow-checks` (which is the default in debug mode).
Given the number of backlinks in the mentioned issues, this seems to be a FP that is worth fixing, probably.

changelog: [`unnecessary_lazy_evaluations`]: don't lint if closure has panicky arithmetic operations
2023-11-17 18:53:15 +00:00
bors
31e38fee23 Auto merge of #11821 - GuillaumeGomez:misspelled-cfg, r=blyxyas
Extend `maybe_misused_cfg` lint over `cfg(test)`

Fixes #11240.

One thought I had is that we could use the levenshtein distance (of 1) to ensure this is indeed `test` that was targeted. But maybe it's overkill, not sure.

changelog: [`maybe_misused_cfg`]: Extend lint over `cfg(test)`

r? `@blyxyas`
2023-11-17 11:49:20 +00:00
Philipp Krones
6fab1485c3
Merge remote-tracking branch 'upstream/master' into rustup 2023-11-16 19:02:04 +01:00
Guillaume Gomez
a621d71b4e Add UI test for mispelled test 2023-11-16 18:07:26 +01:00
y21
7696c9d1d5 allow more div and rem operations that can be checked 2023-11-16 17:30:10 +01:00
y21
23ee33255c lint when relevant sides of binops are constants 2023-11-16 04:49:11 +01:00
bors
3ea5bcf5ee Auto merge of #11809 - hrxi:pr_if_same_then_else_style, r=Alexendoo
Change `if_same_then_else` to be a `style` lint

CC #3770

From https://github.com/rust-lang/rust-clippy/issues/3770#issuecomment-687565594 (`@flip1995):`

> Oh I thought I replied to this: I definitely see now that having this
> as a correctness lint might be the wrong categorization. What we might
> want to do is to just allow this lint, if there are comments in the
> arm bodies. But a good first step would be to downgrade this lint to
> style or complexity. I would vote for style since merging two arms is
> not always less complex.

changelog: [`if_same_then_else`]: Change to be a `style` lint
2023-11-15 12:11:14 +00:00
bors
7ad3373bb1 Auto merge of #11802 - dswij:issue-11765, r=xFrednet
`needless_return_with_question_mark` ignore let-else

Fixes #11765

This PR makes `needless_return_with_question_mark` to ignore expr inside let-else.

changelog: [`needless_return_with_question_mark`] ignore let-else
2023-11-15 10:15:47 +00:00
bors
662ea3f9f4 Auto merge of #11811 - y21:avoid_cx_struct_span_lint, r=Manishearth
disallow calls to `LintContext::struct_span_lint` and `TyCtxt::struct_span_lint_hir`

`LintContext::struct_span_lint` and `TyCtxt::struct_span_lint_hir` don't show the link to the clippy documentation, see: #11805

In #11810, the last few calls to those methods were replaced with `span_lint_*`. It seems like we should just disallow them altogether so that no new code tries to use them.

The existing `disallowed_methods` lint makes this easy.

changelog: none
2023-11-15 07:27:46 +00:00
bors
783b914fae Auto merge of #11804 - y21:issue-11803, r=dswij
[`impl_trait_in_params`]: avoid ICE when function with `impl Trait` type has no parameters

Fixes #11803

If I'm reading the old code correctly, it was taking the span of the first parameter (without checking that it exists, which caused the ICE) and uses that to figure out where the generic parameter to insert should go (cc `@blyxyas` you wrote the lint, is that correct?).
This seemed equivalent to just `generics.span`, which doesn't require calculating the spans like that and simplifies it a fair bit

changelog: don't ICE when function has no parameters but generics have an `impl Trait` type
2023-11-15 04:03:44 +00:00
y21
19eec0b7cc disallow struct_span_lint 2023-11-15 03:20:04 +01:00
hrxi
b3073c536b Change if_same_then_else to be a style lint
CC #3770

From https://github.com/rust-lang/rust-clippy/issues/3770#issuecomment-687565594 (@flip1995):

> Oh I thought I replied to this: I definitely see now that having this
> as a correctness lint might be the wrong categorization. What we might
> want to do is to just allow this lint, if there are comments in the
> arm bodies. But a good first step would be to downgrade this lint to
> style or complexity. I would vote for style since merging two arms is
> not always less complex.
2023-11-15 00:33:14 +01:00
bors
0c42e451d6 Auto merge of #11791 - Jacherr:iter_over_hash_type, r=Jarcho
Implement new lint `iter_over_hash_type`

Implements and fixes https://github.com/rust-lang/rust-clippy/issues/11788

This PR adds a new *restriction* lint `iter_over_hash_type` which prevents `Hash`-types (that is, `HashSet` and `HashMap`) from being used as the iterator in `for` loops.

The justification for this is because in `Hash`-based types, the ordering of items is not guaranteed and may vary between executions of the same program on the same hardware. In addition, it reduces readability due to the unclear iteration order.

The implementation of this lint also ensures the following:
- Calls to `HashMap::keys`, `HashMap::values`, and `HashSet::iter` are also denied when used in `for` loops,
- When this expression is used in procedural macros, it is not linted/denied.

changelog: add new `iter_over_hash_type` lint to prevent unordered iterations through hashed data structures
2023-11-14 15:55:00 +00:00
Yudai Fukushima
a9d42e6d6d fix: reduce [manual_memcpy] indexing when array length is same to loop range
Format

refactor: extract function to shrink function length

fix: remove cmp to calculate range

fix: replace if_chain with let chains
2023-11-14 22:05:44 +09:00
y21
3f6b29ad32 [impl_trait_in_params]: fix span calculation 2023-11-14 13:52:44 +01:00
dswij
48f38eb131 needless_return_with_question_mark ignore let-else 2023-11-14 16:30:52 +08:00
Jacherr
f8ea496495 add tests for type-aliased hash types 2023-11-13 16:52:59 +00:00