fix: incorrect suggestions when `.then` and `.then_some` is used
fixes#11910
In the current implementation of `search_is_some`, if a `.is_none` call is followed by a `.then` or `.then_some` call, the generated `!` will incorrectly negate the values returned by the `then` and `.then_some` calls. To fix this, we need to add parentheses to the generated suggestions when appropriate.
changelog: [`search_is_some`]: add parenthesis to suggestions when appropriate
[`module_name_repetition`] Recognize common prepositions
Fixes#12544
changelog: [`module_name_repetition`]: don't report an item name if it consists only of a prefix from `allowed-prefixes` list and a module name (e.g. `AsFoo` in module `foo`). Prefixes allowed by default: [`to`, `from`, `into`, `as`, `try_into`, `try_from`]
Use `check_attributes` in doc lints
Ensures we catch all the places that doc comments could occur, found one that we were currently missing - docs on `extern` items
changelog: none
Pin `remark-lint-maximum-line-length` version
Pins the remark versions to the ones from before the most recent set of updates which errors on [some line lengths](https://github.com/remarkjs/remark-lint/issues/318) that aren't clear how to resolve
Currently blocking CI
changelog: none
Consistent lint group table in book and README
The lint table and the restriction group description was improved in #10385, but only in the README. Apply the same changes to the book.
r? `@xFrednet`
I noticed that I left review comments about this in #10385, but never submitted them. So to this day they are listed as "pending" in the GitHub UI.
This is just copy and paste of the current README file on `master`.
changelog: none
Fixes#12544.
- don't report an item name if it consists only of a prefix from `allowed-prefixes` list and a module name (e.g. `AsFoo` in module `foo`).
- configured by `allowed-prefixes` config entry
- prefixes allowed by default: [`to`, `from`, `into`, `as`, `try_into`, `try_from`]
- update docs
Correct parentheses for [`needless_borrow`] suggestion
This fixes#12268
Clippy no longer adds unnecessary parentheses in suggestions when the expression is part of a tuple.
---
changelog: Fix [`needless_borrow`] unnecessary parentheses in suggestion.
fix incorrect suggestion for `!(a as type >= b)`
fixes#12625
The expression `!(a as type >= b)` got simplified to `a as type < b`, but because of rust's parsing rules that `<` is interpreted as a start of generic arguments for `type`. This is fixed by recognizing this case and adding extra parens around the left-hand side of the comparison.
changelog: [`nonminimal_bool`]: fix incorrect suggestion for `!(a as type >= b)`
[`manual_unwrap_or_default`]: Check for Default trait implementation in initial condition when linting and use `IfLetOrMatch`
Fixes#12564
changelog: Fix [`manual_unwrap_or_default`] false positive when initial `match`/`if let` condition doesn't implement `Default` but the return type does.
Prevent PR assignments to `@matthiaskrgr`, `@giraffate`, and `@Centri3`
When commenting r? clippy, rustbot takes a random member from the team. I'm setting you kings and queen to be on vacation, so that rustbot doesn't target you.
---
changelog: none
cc: `@matthiaskrgr` `@giraffate` and `@Centri3`
fix ice reporting in lintcheck
Fixes https://github.com/rust-lang/rust-clippy/issues/12185
This PR fixes the lack of reported ICEs within lintcheck by modifying the way in which data is collected from each crate being linted.
Instead of lintcheck only reading `stdout` for warnings, it now also reads `stderr` for any potential ICE (although admittedly, it is not the cleanest method of doing so). If it is detected, it parses the ICE into its message and backtrace separately, and then adds them to the list of outputs via clippy.
Once all outputs are collected, the formatter then proceeds to generate the file as normal.
Note that this PR also has a couple of side effects:
- When clippy fails to process a package, but said failure is not an ICE, the `stderr` will be sent to the console;
- Instead of `ClippyWarning` being the primary struct for everything reported, there is now `ClippyCheckOutput`, an enum which splits the outputs into warnings and ICEs.
changelog: none
Allow `cast` lints in macros
closes: #11738
Removed the `from_expansion` guard clause for cast lints, so that these warnings can be generated for internal macros.
changelog: allow `cast` lints in macros
type certainty: clear `DefId` when an expression's type changes to non-adt
Fixes#12585
The root cause of the ICE in the linked issue was in the expression `one.x`, in the array literal.
The type of `one` is the `One` struct: an adt with a DefId, so its certainty is `Certain(def_id_of_one)`. However, the field access `.x` can then change the type (to `i32` here) and that should update that `DefId` accordingly. It does do that correctly when `one.x` would be another adt with a DefId:
97ba291d5a/clippy_utils/src/ty/type_certainty/mod.rs (L90-L91)
but when it *isn't* an adt and there is no def id (which is the case in the linked issue: `one.x` is an i32), it keeps the `DefId` of `One`, even though that's the wrong type (which would then lead to a contradiction later when joining `Certainty`s):
97ba291d5a/clippy_utils/src/ty/type_certainty/mod.rs (L92-L93)
In particular, in the linked issue, `from_array([one.x, two.x])` would try to join the `Certainty` of the two array elements, which *should* have been `[Certain(None), Certain(None)]`, because `i32`s have no `DefId`, but instead it was `[Certain(One), Certain(Two)]`, because the DefId wasn't cleared from when it was visiting `one` and `two`. This is the "contradiction" that could be seen in the ICE message
... so this changes it to clear the `DefId` when it isn't an adt.
cc `@smoelius` you implemented this initially in #11135, does this change make sense to you?
changelog: none
Reword `arc_with_non_send_sync` note and help messages
Addresses https://github.com/rust-lang/rust-clippy/issues/12608#issuecomment-2029688054
Makes the note more concise and reframes the `Rc` suggestion around whether it crosses threads currently due to a manual `Send`/`Sync` impl or may do in the future
changelog: none
FIX(12334): manual_swap auto fix
Fixed: #12334
Initialization expressions are now generated as needed if the slice index is bound to a variable.
----
changelog: Fix [`manual_swap`]
Do not suggest `assigning_clones` in `Clone` impl
This PR modifies `assigning_clones` to detect situations where the `clone` call is inside a `Clone` impl, and avoids suggesting the lint in such situations.
r? `@blyxyas`
Fixes: https://github.com/rust-lang/rust-clippy/issues/12600
changelog: Do not invoke `assigning_clones` inside `Clone` impl
rename ptr::from_exposed_addr -> ptr::with_exposed_provenance
As discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/To.20expose.20or.20not.20to.20expose/near/427757066).
The old name, `from_exposed_addr`, makes little sense as it's not the address that is exposed, it's the provenance. (`ptr.expose_addr()` stays unchanged as we haven't found a better option yet. The intended interpretation is "expose the provenance and return the address".)
The new name nicely matches `ptr::without_provenance`.
avoid an ICE in `ptr_as_ptr` when getting the def_id of a local
Fixes#12616
`Res::def_id` can panic, so avoid calling it in favor of `opt_def_id`, so we can gracefully handle resolutions that don't have a `DefId` (e.g. local variables) and get a false negative in the worst case, rather than an ICE
changelog: Fix ICE in [`ptr_as_ptr`] when the cast expression is a function call to a local variable
Initialization expressions are now generated when index is bound to a variable.
FIX: Check to see if variables are used after swap
FIX: rename StmtKind::Local to StmtKind::Let
Pause review rotation for y21
Exams are coming up for me and I want to focus on that, so I'd like to pause PR assignments to me for a bit until that's over (will still continue to look at PRs that are assigned to me and might steal some PRs to review if I find the time). :)
--------------
changelog: none
Elide unit variables linted by `let_unit` and use `()` directly instead
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.
fixes: #12594
changelog: Suggestion Fix [`let_unit`]. Clippy will remove unit bindings and replace all their instances in the body with `()`.
