Skip to content

correct version attribute for io_other_error #14282

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 31, 2025

Conversation

lapla-cogito
Copy link
Contributor

r? flip1995

changelog: none

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Feb 23, 2025
@lapla-cogito
Copy link
Contributor Author

lapla-cogito commented Feb 23, 2025

I asked flip to review this because I want to propose something related to CI.

Currently, there are several submitted issues where the "Added in" version of lint rules on the website differs from the actual release version and a similar issue will arise with this new lint as well (which is why I submitted this patch).

These discrepancies are corrected when the lint becomes stable in a release, so these issues usually resolves themselves within a few months. However, this isn’t necessarily obvious to everyone, and simply saying, "It will be fixed eventually," isn't an ideal approach, IMO.

I'm aware that there has been discussion about checking this as part of the release and sync process. But would it be possible to perform some checks through CI instead? Specifically, I'd like to propose the following workflow:

  • The check runs when a PR is opened, synchronized, or enters the merge queue.
  • It extracts only the lines added by the PR using git diff (note that a simple git diff may cause issues, such as when deprecating lint rules).
  • If any added lines contain only #[clippy::version = "${version}"], the check verifies whether the specified version matches the current Clippy version.
  • If #[clippy::version = "${version}"] lines are added, but some have also been deleted (which can happen, for example, when changing a lint path), the check should be skipped to avoid false positives.

@lapla-cogito
Copy link
Contributor Author

Whatever it is, please feel free to merge it as long as the contents of this patch are not wrong.

@samueltardieu
Copy link
Contributor

For info, the discussion on how to correctly mark new lints is ongoing in #14299 and still on @flip1995 agenda.

I'll merge this change in the meantime.

@samueltardieu samueltardieu added this pull request to the merge queue Mar 31, 2025
Merged via the queue into rust-lang:master with commit d28d234 Mar 31, 2025
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants