Changelog for Clippy 1.87 🦡

[alex-semenyuk]

Violets are red,
Roses are blue,
It’s wrong on purpose —
We don’t break tradition.

---

This is cat-penguin of this release nominated by @xFrednet some time ago:

Cats for the next release can be traditionally nominated in the comments :D
Please be more active and cat-minded 😻

---

changelog: none

r? flip1995

[y21]

Thanks for helping with the changelog! Some of the lint categories are incorrect (I assume you took them from the description and they were changed later on in the review process)

[y21]

The #[clippy::version] attributes will need to be updated as well for the newly added lints (e.g. owned_cow currently has #[clippy::version = "1.85.0"] when it should be 1.87.0), though I suppose that's not a blocker for this changelog. Last time, this was also done separately (#14540)

[xFrednet]

This made my day, and it's not even 10 am yet! :D

And you got all the little details with the poem, emoji and picture right. I love it, 10/10

---

The #[clippy::version] attributes will need to be updated as well for the newly added lints (e.g. owned_cow currently has #[clippy::version = "1.85.0"] when it should be 1.87.0), though I suppose that's not a blocker for this changelog. Last time, this was also done separately (#14540)

Good catch @y21. You don't need to split the changes into two commits. I liked it that way, but there is no other reason to do this.

In this regard, I can also share how I usually wrote them (In case this helps):

1. Get the two commits and generate the changes.txt file
2. I often wrote the changelog in a new changes.md file since VS code was taking more resources when editing our long CHANGELOG.md file
   • If you want to, you can filter out changes, which seem less relevant to everyone. People have the list of all merged PRs. This mainly saves time when writing it and distils the changes to the most relevant ones. But this is purely a style question, so find your own way.
3. For each new lint, do a whole text search for pub <lint-name> to correct the #[clippy::version] attribute and copy the lint group into the changelog.
4. Spellcheck changes.md
5. Copy changes.md into CHANGELOG.md
6. Commit, etc. This is a list of all emojis I’ve previously used in case you want to avoid duplicates. I simply tracked these in my Zulip chat: 🪄, 🏫, 🐈, 🎄, 🎃, 🖊️, 🏖️, 👑, 🔨, 🌸, 🐶, 🐞, 🎅, 🚥, 🍎, 🦖, 🐙, 🦀 🎓 🌞 🔰 🤖 🧨 🦜
   • • 🐧 and 🦡 from this and the previous Changelog

---

I want to finish this again off with saying thank you! This is so cute and I love to see that this is carried forward! Because of this ping I also saw the previous changelog PR which is equally amazing. This makes the community special! ❤️

[xFrednet]

And I want to nominate June as the cat of the next release. Look at that cute smile!

(Please ping me when June made it as the cat of the release. I want to send it to her owner :D)

[flip1995]

3. For each new lint, do a whole text search for pub <lint-name> to correct the #[clippy::version] attribute and copy the lint group into the changelog.

Pass -B1 to grep/rg to quickly scan for the #[clippy::version] in the terminal output (should you do it there)

Thanks for summarizing how to most efficiently update the versions! @alex-semenyuk could I ask you to also write this in our documentation?

[flip1995]

After sleeping over this: I would like to keep the "new" style of only mentioning the most important changes, rather than all. This list of changes is really overwhelming IMO.

Sorry for not mentioning this sooner and you adding all of them :/ I know how much work this is...

[alex-semenyuk]

Do you mean "False Positive Fixes" section?

[flip1995]

No, generally. See the previous changelogs, which are quite short. This is because the changelog author made judgements about what entries are important enough to list.

For example, I don't think that

[range_zip_with_len] now has an autofix

will be interesting to most people. On the other hand, changes to configuration values like the first 2 and the last point of ## Enhancements are worth to include in the changelog.

[alex-semenyuk]

Perhaps something like this

### Enhancements

* Add `allow_expect_in_consts` and `allow_unwrap_in_consts` configuration options to [`unwrap_used`], [`expect_used`]
  [#14200](https://github.com/rust-lang/rust-clippy/pull/14200)
* Add `check-incompatible-msrv-in-tests` configuration option to [`incompatible_msrv`]
  [#14279](https://github.com/rust-lang/rust-clippy/pull/14279)
* [`len_zero`] now also triggers if deref target implements `is_empty()`
  [#13871](https://github.com/rust-lang/rust-clippy/pull/13871)
* [`ptr_eq`] now handles more cases, including `!=` in addition to `==`
  [#14339](https://github.com/rust-lang/rust-clippy/pull/14339)
* [`struct_field_names`] now also checks private fields of public structs
  [#14076](https://github.com/rust-lang/rust-clippy/pull/14076)
* [`needless_pass_by_value`] suggests using a reference on the innermost `Option` content
  [#14392](https://github.com/rust-lang/rust-clippy/pull/14392)
* [`obfuscated_if_else`] now supports `then().unwrap_or_else()` and `then_some().unwrap_or_else()`
  [#14165](https://github.com/rust-lang/rust-clippy/pull/14165)
* Format macros: all format-handling lints now validate `todo!` and `unimplemented!` macros
  [#14266](https://github.com/rust-lang/rust-clippy/pull/14266)
* [`disallowed_methods`] now supports replacements
  [#13669](https://github.com/rust-lang/rust-clippy/pull/13669)
* Added MSRV checks for several lints:
  * [`question_mark`] [#14436](https://github.com/rust-lang/rust-clippy/pull/14436)
  * [`repeat_vec_with_capacity`] [#14126](https://github.com/rust-lang/rust-clippy/pull/14126)
  * [`manual_flatten`] [#14086](https://github.com/rust-lang/rust-clippy/pull/14086)
  * [`lines_filter_map_ok`] [#14130](https://github.com/rust-lang/rust-clippy/pull/14130)

As for the rest sections they look quite short, except false positive, but not sure what can be removed from them, seems they're equal

[flip1995]

This selection looks good!

I would say for the FP section, I would remove everything that doesn't give enough information on its own. For example [map_entry] Fix false positive ...: What FP? What was fixed? People won't click on a PR anyway and investigate what exactly was fixed. So those entries could be removed.

So think "Would I understand this change, if I was not working on Clippy, just from this one line?" And if the answer is "No", then it should probably be removed.

[flip1995]

Oh and I think that the ### Suggestion Fixes/Improvements section can be completely removed (also from the docs). I don't think that anyone is interested in that. As in: "Oh this lint suggestion was fixed, so let me re-run cargo clippy --fix again". Probably doesn't happen, as they most likely already fixed the things by hand.

[flip1995]

Awesome thanks!

I personally might have slimmed it down even more, but that's just personal preference (of the changelog author). The current selection is definitely good! If you think those are important, there are others out there that will also find them important, so lets keep it as is.

Thanks again for writing it and addressing my (maybe annoying) review comments! ❤️