Bring up Rust lang #37612 as a known problem for let_and_return
Fixes https://github.com/rust-lang/rust-clippy/issues/4182.
I don't think conforming to this lint could trigger the issue immediately, only if subsequent code-changes go wrong, but I may be mistaken.
Since the lint can't trigger it by itself, just closing this issue might be reasonable, if not maybe this PR fixes it.
changelog: Update docs for `let_and_return`, mention rust-lang #37612
[`unnecessary_lazy_eval`]: don't lint on types with deref impl
Fixes#10437.
This PR changes clippy's util module `eager_or_lazy` to also consider deref expressions whose type has a non-builtin deref impl and not suggest replacing it as that might have observable side effects.
A prominent example might be the `lazy_static` macro, which creates a newtype with a `Deref` impl that you need to go through to get access to the inner value. Going from lazy to eager can make a difference there.
changelog: [`unnecessary_lazy_eval`]: don't lint on types with non-builtin deref impl
Add lints for disallowing usage of `to_xx_bytes` and `from_xx_bytes`
Adds `host_endian_bytes`, `little_endian_bytes` and `big_endian_bytes`
Closes#10765
v - not sure what to put here since this adds 3 lints
changelog: Add `host_endian_bytes`, `little_endian_bytes` and `big_endian_bytes` lints
[`allow_attributes`, `allow_attributes_without_reason`]: Ignore attributes from procedural macros
I use `lint_reasons` and `clap`, which is a bit overzealous when it comes to preventing warnings in its macros; it uses a ton of allow attributes on everything to, as ironic as it is, silence warnings. These two now ignore anything from procedural macros.
PS, I think `allow_attributes.rs` should be merged with `attrs.rs` in the future.
fixes#10377
changelog: [`allow_attributes`, `allow_attributes_without_reason`]: Ignore attributes from procedural macros
Ignore fix for `from_over_into` if the target type contains a `Self` reference
Fixes https://github.com/rust-lang/rust-clippy/issues/10838.
This is my first time contributing here, and the fix is kind of ugly.
I've worked a bit with `quote` and was trying to figure out a way to replace the type in a better way than just a raw string-replace but couldn't quite figure out how to.
The only thing really required to fix this, is to replace all `Self` references with the type stated in the `from` variable, this isn't entirely simple to do with raw strings without creating a mess though.
We need to find and replace all `Self`'s in a variable with `from` but there could be an arbitrary amount, in a lot of different positions. As well as some type that contains the name self, like `SelfVarSelf` which shouldn't be replaced.
The strategy is essentially, if `"Self"` is surrounded on both sides by something that isn't alphanumeric, then we're golden, then trying to make that reasonably efficient.
I would not be offended if the solution is too messy to accept!
changelog: [from_over_into]: Replace Self with the indicated variable in suggestion and fix.
new lint: `explicit_into_iter_fn_arg`
Closes#10743.
This adds a lint that looks for `.into_iter()` calls in a call expression to a function that already expects an `IntoIterator`. In those cases, explicitly calling `.into_iter()` is unnecessary.
There were a few instances of this in clippy itself so I fixed those as well in this PR.
changelog: new lint [`explicit_into_iter_fn_arg`]
manual_let_else: support struct patterns
This adds upon the improvements of #10797 and:
* Only prints `()` around `Or` patterns at the top level (fixing a regression of #10797)
* Supports multi-binding patterns: `let (u, v) = if let (Some(u_i), Ok(v_i)) = ex { (u_i, v_i) } else ...`
* Traverses through tuple patterns: `let v = if let (Some(v), None) = ex { v } else ...`
* Supports struct patterns: `let v = if let S { v, w, } = ex { (v, w) } else ...`
```
changelog: [`manual_let_else`]: improve pattern printing to support struct patterns
```
fixes#10708fixes#10424
[`ptr_cast_constness`]: Only lint on casts which don't change type
fixes#10874
changelog: [`ptr_cast_constness`]: Only lint on casts which don't change type
Emit `unnecessary_cast` on raw pointers as well
Supersedes(?) #10782, since this and #10567 will cover the original issue.
Does not lint on type aliases or inferred types.
changelog: [`unnecessary_cast`]: Also emit on casts between raw pointers with the same type and constness
Clippy Book Chapter Updates Reborn: Refresh Lint Configuration's looks
This PR modernizes and clears up some confusion with the "Lint Configuration Options" chapter from the book.
### Changes
- **Remove 'Option - Default Value" table**
- Why was it even there?
- It shouldn't be the first thing an user sees when they enter the chapter. It's clunky, ugly and not useful. The default values for configs are stated in a per-config basis if needed.
- **Add a simple description of what the chapter contains, and the scheme of each configuration option**
- **Minor formatting, mainly adding code fragments to code text**
- It seemed weird and jarring not having back-ticks on text like "arithmetic_side_effects".
- Improves readability and separation between configs.
- **Separate a little bit the Affected Lints list + "Affected lists" message**
- Not having something indicating that the list is about the lints that use the configuration option is confusing.
- It isn't as important as the description and example. Therefore should be separated a little bit imo
---
This is an independent effort from #10597, but as it's still a Book Chapter Update, I thought it would be cool to include it here. I'm going to keep the reviewing process for this PR to rustbot's desires.
[Rendered](https://github.com/blyxyas/rust-clippy/blob/book-lint_config/book/src/lint_configuration.md)
[Current](https://github.com/rust-lang/rust-clippy/blob/master/book/src/lint_configuration.md)
changelog: Refresh styling from the "Lint Configuration Options" book chapter.
Update *Current stable* text in `CHANGELOG.md`
Roses are red,
violets are blue,
the new version was released,
and our changelog too
---
changelog: none
add checking for cfg(features = ...)
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: [`maybe_misused_cfg`]: check if `#[cfg(feature = "...")]` misused as `#[cfg(features = "...")]`
I've found that there is no indication when `#[cfg(features = "...")]` is used incorrectly, which can easily make mistakes hard to spot. When I searched for this code on github, I also found many misuse cases([link](https://github.com/search?q=%23%5Bcfg%28features+language%3ARust&type=code)).
PS: This clippy name is just a temporary name, it can be replaced with a better name.
