accept `String` in `span_lint*` functions directly to avoid unnecessary clones
context: https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Accepting.20.60Into.3C.7BSub.7DdiagMessage.3E.60.20in.20.60span_lint*.60.20functions/near/425703273
tldr: the `span_lint*` functions now accept both `String`s, which are then reused and not recloned like before, and also `&'static str`, in which case it [doesn't need to allocate](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_error_messages/lib.rs.html#359).
Previously, it accepted `&str` and would always call `.to_string()`, which is worse in any case: it allocates for `&'static str` and forces a clone even if the caller already has a `String`.
---------
This PR has a massive diff, but the only interesting change is in the first commit, which changes the message/help/note parameter in the `span_lint*` functions to not take a `&str`, but an `impl Into<DiagMessage>`.
The second commit changes all of the errors that now occur:
- `&format!(...)` cannot be passed to `span_lint` anymore. Instead, we now simply pass `format!()` directly.
- `Into<DiagMessage>` can be `&'static str`, but not any `&str`. So this requires changing a bunch of other `&str` to `&'static str` at call sites as well.
- Added [`Sugg::into_string`](9fc88bc285/clippy_utils/src/sugg.rs (L362)), which, as opposed to `Sugg::to_string`, can take advantage of the fact that it takes ownership and is able to reuse the `String`
changelog: none
Situation: `let_unit` lints when an expression binds a unit (`()`)
to a variable. In some cases this binding may be passed down to
another function. Currently, the lint removes the binding without
considering usage.
Change: All usages of the elided variable are now replaced with `()`.
fixes: #12594
Move `box_default` to style, do not suggest turbofishes
`Box::default()` [had its `#[rustc_box]` attribute removed](https://github.com/rust-lang/rust/pull/108476/files#r1120930164) in 1.69 so is no longer a perf related lint
The lint is moved to style but no longer produces suggestions containing turbofishes, as they're often longer/more annoying to type
changelog: [`box_default`]: Move to style
r? `@llogiq`
`Box::default()` had its `#[rustc_box]` attribute removed in 1.69 so is
no longer a perf related lint
The lint is moved to style but no longer produces suggestions containing
turbofishes, as they're often longer/more annoying to type
Allow `filter_map_identity` when the closure is typed
This extends the `filter_map_identity` lint to support typed closures.
For untyped closures, we know that the program compiles, and therefore we can safely suggest using flatten.
For typed closures, they may participate in type resolution. In this case we use `Applicability::MaybeIncorrect`.
Details:
https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Should.20.60filter_map_identity.60.20lint.20when.20closures.20are.20typed.3F
changelog: `filter_map_identity` will now suggest using flatten for typed closures.
r? `@y21` && `@Centri3`
[`type_id_on_box`]: lint on any `Box<dyn _>`
Closes#11349.
It now not only lints when calling `.type_id()` on the type `Box<dyn Any>`, but also on any `Box<dyn Trait>` where `Trait` is a subtrait of `Any`
changelog: FN: [`type_id_on_box`]: lint if `Any` is a sub trait
new lint `legacy_numeric_constants`
Rework of #10997
- uses diagnostic items
- does not lint imports of the float modules (`use std::f32`)
- does not lint usage of float constants that look like `f32::MIN`
I chose to make the float changes because the following pattern is actually pretty useful
```rust
use std::f32;
let omega = freq * 2 * f32::consts::PI;
```
and the float modules are not TBD-deprecated like the integer modules.
Closes#10995
---
changelog: New lint [`legacy_numeric_constants`]
[#12312](https://github.com/rust-lang/rust-clippy/pull/12312)
make sure checked type implements `Try` trait when linting [`question_mark`]
(indirectly) fixes: #12412 and fixes: #11983
---
changelog: make sure checked type implements `Try` trait when linting [`question_mark`]
restrict manual_clamp to const case, bring it out of nursery
Implements the plan that I described in https://github.com/rust-lang/rust-clippy/pull/9484#issuecomment-1374522054
This does two things primarily
1. Restrict `manual_clamp` such that it will only trigger if we are able to guarantee that `clamp` won't panic at runtime.
2. Bring `manual_clamp` out of nursery status and move it into the complexity group.
changelog: [`manual_clamp`]: Restrict this lint such that it only triggers if max and min are const, and max is greater than or equal to min. Then bring it out of the nursery group.
Fix typo in comment
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.
It's also helpful for us that the lint name is put within backticks (`` ` ` ``),
and then encapsulated by square brackets (`[]`), for example:
```
changelog: [`lint_name`]: 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]
- \[ ] Added passing UI tests (including committed `.stderr` file)
- \[ ] `cargo test` passes locally
- \[ ] Executed `cargo dev update_lints`
- \[ ] 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.
---
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: None
`large_stack_frames`: print total size and largest component.
Instead of just saying “this function's stack frame is big”, report:
* the (presumed) size of the frame
* the size and type of the largest local contributing to that size
* the configurable limit that was exceeded (once)
Known issues:
* The lint may report an over-estimate because codegen may be able to overlap some of these locals. However, that already affected whether the lint fired at all; I believe this change is still an improvement because it gives the user much more actionable information about _why_ the lint fired.
* Please tell me a better way to determine whether a local has a variable name.
changelog: [`large_stack_frames`]: print total size and largest component.
Instead of just saying “this function's stack frame is big”, report:
* the (presumed) size of the frame
* the size and type of the largest local contributing to that size
* the configurable limit that was exceeded (once)
allow [`manual_unwrap_or_default`] in const function
closes: #12568
---
changelog: allow [`manual_unwrap_or_default`] in const function
This is a small fix, I was originally decided to fix it along with `#12568` but there are some problems needs to be addressed (which is why my branch is called `issue12569` 😆 ), so I decide to open a separated PR to fix them one at a time.
Rename `Inherited` -> `TypeckRootCtxt`
`Inherited` is a confusing name. Rename it to `TypeckRootCtxt`.
I don't think this needs a type MCP or anything since it's not nearly as pervasive as `FnCtxt` , for example.
r? `@lcnr` `@oli-obk`
It turns out there is a bit of a circular dependency - I cannot add
anything to `core` because Clippy fails, and I can't actually add
correct Clippy implementations without new implementations from `core`.
Change some of the Clippy stubs from `unimplemented!` to success values
and leave a FIXME in their place to mitigate this.
Fixes <https://github.com/rust-lang/rust/issues/122587>
RFC: Document Clippy's teams and team duties
First the big announcement:
**We want to add a new subteam for regular contributors to give them triage rights.**
---
This PR adds a new section to the book which describes the Clippy and Clippy-Contributor teams, with their duties and membership requirements. This is just an initial draft, that outlines what, I think, their responsibilities should be.
I hope everyone in the team is okay with me posting this directly to GitHub. I think a PR makes collaboration a bit easier.
[🖼️ Rendered 🖼️](https://github.com/xFrednet/rust-clippy/blob/add-team-docs/book/src/development/the_team.md)
---
Once we've decided on this document, I'll create a PR to add the new team on GitHub. As part of this, we'll also reach out to some active contributors, to ask if they would like to join the new team.
---
cc: `@rust-lang/clippy`
cc: #6627
changelog: none
r? `@flip1995`
Remove `unwrap` from `match_trait_method`
Unused_IO_amount relies on `match_trait_method` in order to match trait methods that exist in Tokio traits as the corresponding symbols don't exist.
With this commit we remove the unwrap that caused #12366.
Note: author (`@m-rph)` and `@GuillaumeGomez` couldn't replicate #12366.
changelog:none
r? `@blyxyas`
Change applicability of `assigning_clones` to `Unspecified`
Before we deal with https://github.com/rust-lang/rust-clippy/pull/12473 and the borrow checker errors, I think that it would be better to downgrade this lint, since it can break code.
changelog: Change the applicability of `assigning_clones` to `Unspecified`
r? `@blyxyas`
[`let_and_return`]: avoid linting when code between last stmt and return expr is cfg'd out
Fixes#9150
This moves `span_contains_cfg` to utils and starts using it in `let_and_return` as well.
changelog: [`let_and_return`]: avoid linting when code between the last statement and the final return expression is `#[cfg]`ed out
fix: `suspicious_else_formatting` false positive when else is included …
This PR addresses an issue where invalid suggestions are generated for `if-else` formatting if comments contain the keyword `else`.
The root of the problem is identified [here](95c62ffae9/clippy_lints/src/formatting.rs (L217)). Specifically, when a comment contains the word `else`, the lint mistakenly interprets it as part of an `if-else` clause. This misinterpretation leads to an incorrect splitting of the snippet, resulting in erroneous suggestions.
fixes: #12497
changelog: [`suspicious_else_formatting`]: Fixes invalid suggestions when comments include word else
Remove unnecessary dot in the 'unconditional recursion' lint description
I don't think such changes should be reflected in the changelog.
changelog: none
