Add `Unsupported` to `std::io::ErrorKind`
I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations.
The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just "an unspecified error occurred", which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`.
**Implementation**:
The following variant will be added to `std::io::ErrorKind`:
```rust
/// This operation is unsupported on this platform.
Unsupported
```
`std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform, and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate, e.g. on wasm for file and network operations.
`decode_error_kind` will be updated to decode operating system errors to `Unsupported`:
- Unix and VxWorks: `libc::ENOSYS`
- Windows: `c::ERROR_CALL_NOT_IMPLEMENTED`
- WASI: `wasi::ERRNO_NOSYS`
**Stability**:
This changes the kind of error returned by some functions on some platforms, which I think is not covered by the stability guarantees of the std? User code could depend on this behavior, expecting `ErrorKind::Other`, however the docs already mention:
> Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics, e.g., a specific `Error::raw_os_error` return value.
The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago), but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it, so adding a new variant per se should not be a breaking change.
The variant `Unsupported` itself could be marked as `#[unstable]`, however, because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.
Allow allman style braces in `suspicious_else_formatting`
fixes: #3864
Indentation checks could be added as well, but the lint already doesn't check for it.
changelog: Allow allman style braces in `suspicious_else_formatting`
Fixing FPs for the `branches_sharing_code` lint
Fixes#7053Fixes#7054
And an additional CSS adjustment to support dark mode for every inline code. It currently only works in paragraphs, which was an oversight on my part 😅. [Current Example](https://rust-lang.github.io/rust-clippy/master/index.html#blacklisted_name)
This also includes ~50 lines of doc comments and is therefor not as big as the changes would indicate. 🐧
---
changelog: none
All of these bugs were introduced in this dev version and are therefor not worth a change log entry.
r? `@phansch`
cc: `@camsteffen` since you have a pretty good overview of the `SpanlessEq` implementation 🙃
Add `cloned_instead_of_copied` lint
Don't go cloning all willy-nilly.
Featuring a new `get_iterator_item_ty` util!
changelog: Add cloned_instead_of_copied lint
Closes#3870
Fix: redundant_pattern_matching drop order
Fixes#5746
A note about the change in drop order is added when the scrutinee (or any temporary in the expression) isn't known to be safe to drop in any order (i.e. doesn't implement the `Drop` trait, or contain such a type). There is a whitelist for some `std` types, but it's incomplete. Currently just `Vec<_>`, `Box<_>`, `Rc<_>` and `Arc<_>`, but only if the contained type is also safe to drop in any order.
Another lint for when the drop order changes could be added as allowed by default, but the drop order requirement is pretty subtle in this case. I think the note added to the lint should be enough to make someone think before applying the change.
changelog: Added a note to `redundant_pattern_matching` when the change in drop order might matter
Improve `map_entry` suggestion
fixes: #5176fixes: #4674fixes: #4664fixes: #1450
Still need to handle the value returned by `insert` correctly.
changelog: Improve `map_entry` suggestion. Will now suggest `or_insert`, `insert_with` or `match _.entry(_)` as appopriate.
changelog: Fix `map_entry` false positives where the entry api can't be used. e.g. when the map is used for multiple things.
Don't allow adjustments for `manual_map`
fixes: #7077
The other option here would be to add the return type to the closure. It would be fine for simple types, but longer types can be rather unwieldy. Could also implement the adjustment manually.
changelog: Don't lint `manual_map` when type adjustments are added. e.g. autoderef
Fix false positives where the map is used before inserting into the map.
Fix false positives where two insertions happen.
Suggest using `if let Entry::Vacant(e) = _.entry(_)` when `or_insert` might be a semantic change
tabs_in_doc_comments: Fix ICE due to char indexing
This is a quick-fix for an ICE in `tabs_in_doc_comments`. The problem
was that we we're indexing into possibly multi-byte characters, such as '位'.
More specifically `get_chunks_of_tabs` was returning indices into
multi-byte characters. Those were passed on to a `Span` creation that
then caused the ICE.
This fix makes sure that we don't return indices that point inside a
multi-byte character. *However*, we are still iterating over unicode
codepoints, not grapheme clusters. So a seemingly single character like y̆ ,
which actually consists of two codepoints, will probably still cause
incorrect spans in the output. But I don't think we handle those cases
anywhere in Clippy currently?
Fixes#5835
changelog: Fix ICE in `tabs_in_doc_comments`
Fix FP in `wrong_self_convention` lint
Previously, this lint didn't check into impl block when it was implementing a trait.
Recent improvements (#6924) have moved this check and some impl blocks are now checked but they shouldn't, such as in #7032.
Fixes#7032
changelog: Fix FP when not taking `self` in impl block for `wrong_self_convention` lint
Deprecate `filter_map`
Since #6591, `filter_map` does not even lint `filter().map()`. The cases that are still linted make no sense IMO. So this just removes/deprecates it.
changelog: Deprecate `filter_map` lint
Closes#3424Fixes#7050
Fix FP in `single_component_path_imports` lint
Fix FP in `single_component_path_imports` lint when the import is reused with `self`, like in `use self::module`.
Fixes#5210
changelog: none
Invalid null usage v2
This is continuation of #6192 after inactivity.
I plan to move paths into the compiler as diagnostic items after this is merged.
fixes#1703
changelog: none
consider mutability on useless_vec suggestions
fixes#7035
changelog: Now the suggested by `useless_vec` considers mutability to suggest either `&[]`, as before, or `&mut []` if the used reference is mutable.
This is a quick-fix for an ICE in `tabs_in_doc_comments`. The problem
was that we we're indexing into possibly multi-byte characters, such as '位'.
More specifically `get_chunks_of_tabs` was returning indices into
multi-byte characters. Those were passed on to a `Span` creation that
then caused the ICE.
This fix makes sure that we don't return indices that point inside a
multi-byte character. *However*, we are still iterating over unicode
codepoints, not grapheme clusters. So a seemingly single character like y̆ ,
which actually consists of two codepoints, will probably still cause
incorrect spans in the output.
Don't trigger `same_item_push` if the vec is used in the loop body
fixes#6987
changelog: `same_item_push`: Don't trigger if the `vec` is used in the loop body
fix `missing_panics_doc` not detecting `assert_eq!` and `assert_ne!`
fixes#6997
changelog: `missing_panics_doc` detects `assert_eq!` and `assert_ne!`
---
searching for `assert_eq!` and `assert_ne!` in `FindPanicUnwrap`
* Added expression check for shared_code_in_if_blocks
* Finishing touches for the shared_code_in_if_blocks lint
* Applying PR suggestions
* Update lints yay
* Moved test into subfolder
Fix `redundant_clone` fp
fixes: #5973fixes: #5595fixes: #6998
changelog: Fix `redundant_clone` fp where the cloned value is modified while the clone is in use.
Lint: filter(Option::is_some).map(Option::unwrap)
Fixes#6061
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog:
* add new lint for filter(Option::is_some).map(Option::unwrap)
First Rust PR, so I'm sure I've violated some idioms. Happy to change anything.
I'm getting one test failure locally -- a stderr diff for `compile_test`. I'm having a hard time seeing how I could be causing it, so I'm tentatively opening this in the hopes that it's an artifact of my local setup against `rustc`. Hoping it can at least still be reviewed in the meantime.
I'm gathering that since this is a method lint, and `.filter(...).map(...)` is already checked, the means of implementation needs to be a little different, so I didn't exactly follow the setup boilerplate. My way of checking for method calls seems a little too direct (ie, "is the second element of the expression literally the path for `Option::is_some`?"), but it seems like that's how some other lints work, so I went with it. I'm assuming we're not concerned about, eg, closures that just end up equivalent to `Option::is_some` by eta reduction.
disable upper_case_acronyms for pub items - enum edition
Fixes https://github.com/rust-lang/rust-clippy/issues/6803 (again... 😅 )
My previous fix did not work for enums because enum variants were checked separately in the `check_variant` function but it looks like we can't use that because we can't tell if the enum the variants belong to is declared as public or not (it always said `Inherited` for me)
I went and special-cased enums and iterated over all the variants "manually", but only, if the enums is not public.
---
changelog: fix upper_case_acronyms still firing on public enums (#6803)
Refactor types
r? `@flip1995`
This is the last PR to close#6724🎉
Also, this fixes#6936.
changelog: `vec_box`: Fix FN in `const` or `static`
changelog: `linkedlist`: Fix FN in `const` or `static`
changelog: `option_option`: Fix FN in `const` or `static`
Improve `clone_on_copy`
This also removes the `clone_on_copy_mut` test as the same thing is covered in the `clone_on_copy` test.
changelog: `copy_on_clone` lint on chained method calls taking self by value
changelog: `copy_on_clone` only lint when using the `Clone` trait
changelog: `copy_on_clone` correct suggestion when the cloned value is a macro call.
Lint on `_.clone().method()` when method takes self by value
Set applicability correctly
Correct suggestion when the cloned value is a macro call. e.g. `m!(x).clone()`
Don't lint when not using the `Clone` trait
Improve `expl_impl_clone_on_copy`
fixes: #1254
changelog: Check to see if the generic constraints are the same as if using derive for `expl_impl_clone_on_copy`
`len_without_is_empty` improvements
fixes: #6958fixes: #6972
changelog: Check the return type of `len`. Only integral types, or an `Option` or `Result` wrapping one.
changelog: Ensure the return type of `is_empty` matches. e.g. `Option<usize>` -> `Option<bool>`
Check the return type of `len`. Only integral types, or an `Option` or `Result` wrapping one.
Ensure the return type of `is_empty` matches. e.g. `Option<usize>` -> `Option<bool>`
When the character next to `{}` is "shifted" (when mapping a byte index
in the format string to span) we should avoid shifting the span end
index, so first map the index of `}` to span, then bump the span,
instead of first mapping the next byte index to a span (which causes
bumping the end span too much).
Regression test added.
Fixes#83344
Fix bad suggestion when a reborrow might be required
Fix bad suggestion when the value being sliced is a macro call
Don't lint inside of a macro due to the previous context sensitive changes
search_is_some: add checking for `is_none()`
fixes: #6815
changelog: search_is_some: add checking for `is_none()`.
To be honest I don't know what is the process of renaming the lints. Appreciate any feedback if that needs to be handled differently. Thanks!
Fix bad suggestion for `match_single_binding` lint
Fix a bad suggestion that needs curly braces when the target `match` is the body of an arm.
Fixes#6572
changelog: none
`match_wildcard` improvements
fixes: #6604fixes: #5733fixes: #6862#5733 is only fixed in the normal case, if different paths are used for the variants then the same problem will occur. It's cause by `def_path_str` returning an utterly useless result. I haven't dug into why yet.
For #6604 there should be some discussion before accepting this. It's easy enough to change the message rather than disable the lint for `Option` and `Result`.
changelog: Attempt to find a common path prefix for `match_wildcard_for_single_variants` and `wildcard_enum_match_arm`
changelog: Don't lint op `Option` and `Result` for `match_wildcard_for_single_variants` and `wildcard_enum_match_arm`
changelog: Consider `or` patterns and `Self` prefix for `match_wildcard_for_single_variants` and `wildcard_enum_match_arm`
Don't lint on `Result` and `Option` types.
Considers `or` patterns.
Considers variants prefixed with `Self`
Suggestions will try to find a common prefix rather than just using the full path
Write literal suggestion
fixes: #6768
changelog: Add suggestion to `write_literal` and `print_literal` lints
changelog: Change `use_debug` to point only at the format string
wrong_self_convention: fix lint in case of `to_*_mut` method
fixes#6758
changelog: wrong_self_convention: fix lint in case of `to_*_mut` method. When a method starts with `to_` and ends with `_mut`, clippy expects a `&mut self` parameter, otherwise `&self`.
Any feedback is welcome. I was also thinking if shouldn't we treat `to_` the same way as `as_`. Namely to accept `self` taken: `&self` or `&mut self`.
replace span_lint with span_lint_and_sugg along with error message
fixes: #6874
changelog: none
apologies if this may not be the most idiomatic way of doing it, any advice on changes (if any) would be greatly appreciated.
mem_replace_with_default: recognize some std library ctors
fixes#6562
changelog: mem_replace_with_default: recognize some common constructors equivalent to `Default::default()`
Fix suggestion for `explicit_deref_methods`. Sometimes `&**` is needed, sometimes nothing is needed.
Allow `explicit_deref_methods` to trigger in a few new contexts.
`explicit_deref_methods` will now consider ufcs calls
Fix false positives on procedural macros of `missing_inline_in_public_items` lint
Fixes#6486.
changelog: Fix false positives on procedural macros of `missing_inline_in_public_items` lint.
Fix ICE 6840 - make is_normalizable more strict
fixes#6840
make `is_normalizable` more strict, which should catch this ICE and related cases
changelog: Fix ICE in [`zero_sized_map_values`]
Compare empty blocks for equality based on tokens
fixes: #1390
This only considers empty blocks for now, though we should also catch something like this:
```rust
match 0 {
0 => {
do_something();
trace!(0);
0
}
1 => {
do_something();
trace!(1);
1
}
x => x,
}
```
As far as I can tell there aren't any negative effects on other lints. These blocks only happen to be the same for a given compilation, not all compilations.
changelog: Fix `match_on_same_arms` and others. Only consider empty blocks equal if the tokens contained are the same.
Fix `manual_map` false positives
fixes: #6795fixes: #6797fixes: #6811fixes: #6819
changelog: Fix false positives for `manual_map` when `return`, `break`, `continue`, `yield`, `await`, and partially moved values are used.
changelog: Don't expand macros in suggestions for `manual_map`
Fix false positive for unit_arg lint
Fixes#6447
To avoid false positives don't complain about unit args when they come from a path expression, e.g. a local variable.
**Note:** This is my first contribution to Clippy, so I might have messed up somewhere. Any feedback is welcome and I'm happy to work out any kinks.
---
changelog: Do not lint unit arguments when they come from a path expression.
or_fun_call: fix suggestion for `or_insert(vec![])`
fixes#6748
changelog: or_fun_call: fix suggestion for `or_insert(vec![])` on `std::collections::hash_map::Entry` or `std::collections::btree_map::Entry`
Applies for `std::collections::hash_map::Entry` and `std::collections::btree_map::Entry`
Example:
Previously, for the following code:
`let _ = hash_map.entry("test".to_owned()).or_insert(vec![]);`
clippy would suggest to use:
`or_insert_with(vec![])`, which causes a compiler error (E0277).
Now clippy suggests:
`or_insert_with(Vec::new)`
move upper_case_acronyms back to style, but make the default behaviour less aggressive by default (can be unleashed via config option)
Previous discussion in the bi-weekly clippy meeting for reference: https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Meeting.202021-02-23/near/227458019
Move the `upper_case_acronyms` lint back to the style group.
Only warn on fully-capitalized names by default.
Add add a clippy-config option `upper-case-acronyms-aggressive: true/false` to enabled more aggressive linting on
all substrings that could be capitalized acronyms.
---
changelog: reenable upper_case_acronyms by default but make the more aggressive linting opt-in via config option
Inconsistent struct constructor
fixes: #6352
r? `@matthiaskrgr`
I added the lint that checks for the struct constructors where the order of the field init shorthands is inconsistent with that in the struct definition.
changelog: Add style lint: `inconsistent_struct_constructor`
Fix FP in inherent_to_string when the function has generic parameters
Minimal example of the false positive:
````
struct G;
impl G {
fn to_string<const _N: usize>(&self) -> String {
"G.to_string()".to_string()
}
}
fn main() {
let g = G;
g.to_string::<1>();
}
````
Clippy emits an `inherent_to_string` warning, and suggests that we implement `Display` for `G` instead. However, this is not possible, since the generic parameter _N only exists in this function, not in `G` itself. This particular example uses const generics, which is where the issue is most likely to come up, but this PR skips the lint if the `to_string` function has any kind of generic parameters.
changelog: Fix FP in `inherent_to_string`
Teach SpanlessEq binding IDs
changelog: Fix collapsible_match false positive
Fixes#6740
This PR changes the way `SpanlessEq` determines whether two local variables are the same. Instead of checking that the names match, it checks that the `HirId`s match. If local bindings are declared within the expressions that are being compared, `SpanlessEq` will remember bindings that correspond to each other in a `FxHashMap<HirId, HirId>`. This makes `SpanlessEq` more flexible while also fixing false positives.
Example: `{ let x = 1; x + 2 }` is equal to `{ let y = 1; y + 2 }`.
CC `@xFrednet` I think this will resolve some concerns in #6463
Add the from_str_radix_10 lint
changelog: added the new `from_str_radix_10` which sometimes replaces calls to `primitive::from_str_radix` to `str::parse`
This is ready to be merged, although maybe the category should be `pedantic` instead of `style`? I'm not sure where it fits better.
Closes#6713.
Fix for issue 6640
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: unnecessary_wraps will now suggest to remove unnecessary wrapped return unit type, like Option<()>
fixes#6640
New lint: default_numeric_fallback
fixes#6064
r? `@flip1995`
As we discussed in [here](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Issue.20.236064/near/224647188) and [here](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Issue.20clippy.236064/near/224746333), I start implementing this lint from the strictest version.
In this PR, I'll allow the below two cases to pass the lint to reduce FPs.
1. Appearances of unsuffixed numeric literals in `Local` if `Local` has a type annotation, for example:
```rust
// Good.
let x: i32 = 1;
// Also good.
let x: (i32, i32) = if cond {
(1, 2)
} else {
(2, 3)
};
```
2. Appearances of unsuffixed numeric literals in args of `Call` or `MethodCall` if corresponding arguments of their signature have concrete types, for example:
```rust
fn foo_mono(x: i32) -> i32 {
x
}
fn foo_poly<T>(t: T) -> t {
t
}
// Good.
let x = foo_mono(13);
// Still bad.
let x: i32 = foo_poly(13);
```
changelog: Added restriction lint: `default_numeric_fallback`
Do not lint when the closure is called using an iterator
Fix FP when the closure is used in an iterator for `blocks_in_if_conditions` lint
FIxes: #1141
changelog: none
Rework use_self impl based on ty::Ty comparison #3410 | Take 2
This builds on top of #5531
I already reviewed and approved the commits by `@montrivo.` So only the review of my commits should be necessary.
I would also appreciate your review `@montrivo,` since you are familiar with the challenges here.
Fixes#3410 and Fixes#4143 (same problem)
Fixes#2843Fixes#3859Fixes#4734 and fixes#6221Fixes#4305Fixes#5078 (even at expression level now 🎉)
Fixes#3881 and Fixes#4887 (same problem)
Fixes#3909
Not yet: #4140 (test added)
All the credit for the fixes goes to `@montrivo.` I only refactored and copy and pasted his code.
changelog: rewrite [`use_self`] lint and fix multiple (8) FPs. One to go.
Fix suggestions that need parens in `from_iter_instead_of_collect` lint
Fixes broken suggestions that need parens (i.e.: range)
Fixes: #6648
changelog: none
This renames the variants in HIR UnOp from
enum UnOp {
UnDeref,
UnNot,
UnNeg,
}
to
enum UnOp {
Deref,
Not,
Neg,
}
Motivations:
- This is more consistent with the rest of the code base where most enum
variants don't have a prefix.
- These variants are never used without the `UnOp` prefix so the extra
`Un` prefix doesn't help with readability. E.g. we don't have any
`UnDeref`s in the code, we only have `UnOp::UnDeref`.
- MIR `UnOp` type variants don't have a prefix so this is more
consistent with MIR types.
- "un" prefix reads like "inverse" or "reverse", so as a beginner in
rustc code base when I see "UnDeref" what comes to my mind is
something like "&*" instead of just "*".
Add new lint `filter_map_identity`
<!--
Thank you for making Clippy better!
We're collecting our changelog from pull request descriptions.
If your PR only includes internal changes, you can just write
`changelog: none`. Otherwise, please write a short comment
explaining your change.
If your PR fixes an issue, you can add "fixes #issue_number" into this
PR description. This way the issue will be automatically closed when
your PR is merged.
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.
- \[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`
[lint_naming]: https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints
Note that you can skip the above if you are just opening a WIP PR in
order to get feedback.
Delete this line and everything above before opening your PR.
-->
This commit adds a new lint named filter_map_identity.
This lint is the same as `flat_map_identity` except that it checks for the usage of `filter_map`.
---
Closes#6643
changelog: Added a new lint: `filter_map_identity`
Adds a new lint that checks if there is a semicolon on the last block statement if it returns nothing
changelog: Added a new lint: `SEMICOLON_IF_NOTHING_RETURNED`
fixes#6467
Adds the `SEMICOLON_IF_NOTHING_RETURNED` lint and therefore closes#6467.
This commit adds a new lint named `filter_map_identity`. This lint is
the same as `flat_map_identity` except that it checks for `filter_map`.
Closes#6643
New Lint: Manual Flatten
This is a draft PR for [Issue 6564](https://github.com/rust-lang/rust-clippy/issues/6564).
r? `@camsteffen`
- \[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`
---
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: Add new lint [`manual_flatten`] to check for loops over a single `if let` expression with `Result` or `Option`.
Fix file names of flat_map_identity test
This patch fixes the file names of the `flat_map_identity` test.
Previously, their names were started with `unnecessary_flat_map` even though the lint rule name is `flat_map_identity`. This inconsistency happened probably because the rule name was changed during the discussion in the PR where this rule was introduced.
ref: https://github.com/rust-lang/rust-clippy/pull/4231
changelog: none
This commit fixes the file names of the `flat_map_identity` test.
Previously, their names were started with `unnecessary_flat_map` even
though the lint rule name is `flat_map_identity`. This inconsistency
happened probably because the rule name was changed during the
discussion in the PR where this rule was introduced.
ref: https://github.com/rust-lang/rust-clippy/pull/4231
Fix let_and_return false positive
The issue:
See this Rust playground link: https://play.rust-lang.org/?edition=2018&gist=12cb5d1e7527f8c37743b87fc4a53748
Run the above with clippy to see the following warning:
```
warning: returning the result of a `let` binding from a block
--> src/main.rs:24:5
|
23 | let value = Foo::new(&x).value();
| --------------------------------- unnecessary `let` binding
24 | value
| ^^^^^
|
= note: `#[warn(clippy::let_and_return)]` on by default
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#let_and_return
help: return the expression directly
|
23 |
24 | Foo::new(&x).value()
|
```
Implementing the suggested fix, removing the temporary let binding,
yields a compiler error:
```
error[E0597]: `x` does not live long enough
--> src/main.rs:23:14
|
23 | Foo::new(&x).value()
| ---------^^-
| | |
| | borrowed value does not live long enough
| a temporary with access to the borrow is created here ...
24 | }
| -
| |
| `x` dropped here while still borrowed
| ... and the borrow might be used here, when that temporary is dropped and runs the `Drop` code for type `Foo`
|
= note: the temporary is part of an expression at the end of a block;
consider forcing this temporary to be dropped sooner, before the block's local variables are dropped
help: for example, you could save the expression's value in a new local variable `x` and then make `x` be the expression at the end of the block
|
23 | let x = Foo::new(&x).value(); x
| ^^^^^^^ ^^^
```
The fix:
Of course, clippy looks like it should already handle this edge case;
however, it appears `utils::fn_def_id` is not returning a `DefId` for
`Foo::new`. Changing the `qpath_res` lookup to use the child Path
`hir_id` instead of the parent Call `hir_id` fixes the issue.
changelog: none
Implement Rust 2021 panic
This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007.
It does so by replacing `{std, core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller.
This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: c5273bdfb2 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.
Do not lint when range is completely included into another one
This fix has been developed following this [comment](https://github.com/rust-lang/rust-clippy/issues/5986#issuecomment-703313548).
So this will be linted:
```
|----------|
|-----------|
```
Now this won't be linted:
```
|---|
|--------------------|
```
and this will still lint:
```
|--------|
|--------------|
```
Fixes: #5986
changelog: Fix FPs in match_overlapping_arm, when first arm is completely included in second arm
The issue:
See this Rust playground link: https://play.rust-lang.org/?edition=2018&gist=12cb5d1e7527f8c37743b87fc4a53748
Run the above with clippy to see the following warning:
```
warning: returning the result of a `let` binding from a block
--> src/main.rs:24:5
|
23 | let value = Foo::new(&x).value();
| --------------------------------- unnecessary `let` binding
24 | value
| ^^^^^
|
= note: `#[warn(clippy::let_and_return)]` on by default
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#let_and_return
help: return the expression directly
|
23 |
24 | Foo::new(&x).value()
|
```
Implementing the suggested fix, removing the temporary let binding,
yields a compiler error:
```
error[E0597]: `x` does not live long enough
--> src/main.rs:23:14
|
23 | Foo::new(&x).value()
| ---------^^-
| | |
| | borrowed value does not live long enough
| a temporary with access to the borrow is created here ...
24 | }
| -
| |
| `x` dropped here while still borrowed
| ... and the borrow might be used here, when that temporary is dropped and runs the `Drop` code for type `Foo`
|
= note: the temporary is part of an expression at the end of a block;
consider forcing this temporary to be dropped sooner, before the block's local variables are dropped
help: for example, you could save the expression's value in a new local variable `x` and then make `x` be the expression at the end of the block
|
23 | let x = Foo::new(&x).value(); x
| ^^^^^^^ ^^^
```
The fix:
Of course, clippy looks like it should already handle this edge case;
however, it appears `utils::fn_def_id` is not returning a `DefId` for
`Foo::new`. Changing the `qpath_res` lookup to use the child Path
`hir_id` instead of the parent Call `hir_id` fixes the issue.
Similar names ignore underscore prefixed names
changelog: Ignore underscore-prefixed names for similar_names
IMO, this lint is not very helpful for underscore-prefixed variables. Usually they are unused or are just there to ignore part of a destructuring.
Fix formatting for removed lints
- Don't add backticks for the reason a lint was removed. This is almost
never a code block, and when it is the backticks should be in the reason
itself.
- Don't assume clippy is the only tool that needs to be checked for
backwards compatibility
I split this out of https://github.com/rust-lang/rust/pull/80527/ because it kept causing tests to fail, and it's a good change to have anyway.
r? `@flip1995`
Doc markdown
I added "WebGL" along the lines of the existing "OpenGL" to the whitelist of `doc_markdown` as I found this to be a pretty common term.
(this is a follow-up of the now closed https://github.com/rust-lang/rust-clippy/pull/6388)
changelog: Whitelist "WebGL" in `doc_markdown`.
Fix false positive in write_literal and print_literal (numeric literals)
changelog: No longer lint numeric literals in [`write_literal`] and [`print_literal`].
Fixes#6335
It is fairly common to divide some length in bytes by the byte-size of a
single element before creating a `from_raw_parts` slice or similar
operation. This lint would erroneously disallow such expressions.
Just in case, instead of simply disabling this lint in the RHS of a
division, keep track of the inversion and enable it again on recursive
division.
An upcoming test case for new expresssion variants make the stderr file
go over 200 lines. Split this test case in two to have a clear
distinction between checking whether the lint is still applying on
all the functions with member counts as argument, versus validating
various member-count expressions that may or may not be invalid.
New Lint: inspect_then_for_each
**Work In Progress**
This PR addresses [Issue 5209](https://github.com/rust-lang/rust-clippy/issues/5209) and adds a new lint called `inspect_then_for_each`.
Current seek some guidance.
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.
- \[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`
[lint_naming]: https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints
---
changelog: Add [`inspect_for_each`] lint for the use of `inspect().for_each()` on `Iterators`.
- Don't add backticks for the reason a lint was removed. This is almost
never a code block, and when it is the backticks should be in the reason
itself.
- Don't assume clippy is the only tool that needs to be checked for
backwards compatibility
New lint: redundant_slicing
changelog: Added lint: `redundant_slicing`
fixes#6519
This will trigger on any type which implements `Index<RangeFull>` that returns the input type. This would be a false positive if the implementation does something other than return itself, but I'm not sure why you would ever want to do that.
Fix the ICE 6539
Fixes#6539
It happened because `zero_sized_map_values` used `layout_of` with types from type aliases, which is essentially the same as the ICE 4968.
---
changelog: Fix an ICE in `zero_sized_map_values`
Fix FP with empty return for `needless_return` lint
This fixes a false positive in `needless_return` lint, when triggered in a closure using `return` statement without value.
Fixes: #6501
changelog: none
Case sensitive file extensions
Closes#6425
Looks for ends_with methods calls with case sensitive extension comparisons.
changelog: Add new lint that warns about case-sensitive file extension comparisons.
