"Updated In" for lints

[yoav-lavi]

Description

Clippy currently has an "Added in" field for lints, I think it'd be a good idea to introduce an "Updated In" field that has the version in which fixes / improvements / category changes were made.

Of course since it wouldn't necessarily make sense to retroactively add it to existing lints, it could be an Option

Version

rustc 1.62.0 (a8314ef7d 2022-06-27)
binary: rustc
commit-hash: a8314ef7d0ec7b75c336af2c9857bfaf43002bfc
commit-date: 2022-06-27
host: aarch64-apple-darwin
release: 1.62.0
LLVM version: 14.0.5

Additional Labels

No response

[xFrednet]

Hmm, this was something I considered, but decided against it at first, since I don't see a good use case for it unless we add information, what has been fixed/updated. Also related, currently it requires a bit of maintenance work, to keep the added version correct, having a field with updated sounds difficult to keep correct.

This is not a direct no, just my though on the matter :)

[yoav-lavi]

Hey @xFrednet!

Yes, I remember we discussed the maintenance issue in a different issue recently (you must get a lot of these so no worries if you don't recall! 🙂), and I understand the reasoning for not adding it at the moment.

I do think it'd be helpful if you run into a change or issue with an existing codebase (since currently you'll see the creation version which won't validate your assumption that something changed), and perhaps it could be automated at some point or stored outside the repo, but it's more of suggestion than a must, I haven't run into such a case myself yet.

[xFrednet]

I recall, the workload is currently manageable, due to our new team members and the summer time 🙃.

I believe that the most common use case would be, to look if a lint was updated in the hope that a false positive was fixed. When I see that a lint in question was updated, I would then check the changelog. I hope that we can soon stabilize the #[expect] attribute and reason field (RFC 2383) which would cover this use case. 🙃

Now, based on this suggestion, we could actually update the changed in field automatically based on the changelog. The lint names are all listed there, with the latest change version. If someone comes up with a good use case, I feel like that would be a good option. Until then, I would hold off on implementing this. (Even if I like tinkering on the internals of Clippy xD)

[yoav-lavi]

and the summer time

Interesting, do more people contribute in the summer? Students / Educators specifically or in general?

Edit: Or you may have meant yourself which makes the above question irrelevant 🙂

Regarding the suggestion - I understand, this was more of an idea / suggestion than something I personally have a need for, sounds good!

Theoretically it could also be possible to store this data outside of the Clippy
codebase (either manually or by detecting changes to files), but it'd also have (different) overhead considerations.

Thanks!

[xFrednet]

and the summer time

Interesting, do more people contribute in the summer? Students / Educators specifically or in general?

This is only my second year contributing to an open-source project, so take this with a grain of salt. I have the impression, that most contributors are less active in summer. On the other hand, it feels like we have more new contributors lately.

Edit: Or you may have meant yourself

Not at all, my past few months have been super full, due to RL stuff. Luckily, it worked out so far.

Theoretically it could also be possible to store this data outside of the Clippy
codebase (either manually or by detecting changes to files), but it'd also have (different) overhead considerations.

That's a cool idea. I would prefer that solution, if this feature get's more support.