rust-lang
Create new lints with `#[clippy::version = "dev"]`
This is a partial solution to https://rust-lang.zulipchat.com/#narrow/channel/257328-clippy/topic/Using.20CURRENT_RUSTC_VERSION.20in.20clippy.3A.3Aversion.3F
I was not sure if CURRENT_RUSTC_VERSION would work for the stable/beta doc generation so there's no automation here, the versions still need to be manually corrected during the changelog update. But it will eventually (when we're past old PRs with verison = "1.xy.0") solve the issue of wrong versions being shown in the docs
If we figure out that CURRENT_RUSTC_VERSION can be made to work it would be easy enough to move to also
r? @flip1995
cc @xFrednet
changelog: none
(Long text about a problem where I think I came up with a solution while spelling it out. Jump to the last paragraph, if you only want to know the solution)
This is a bit awkward for beta/stable branching (what triggers the doc generation):
To get the beta commit of Clippy, I check which commit of Clippy is in the beta branch in the Rust repo. This commit is always the commit of the sync 2 weeks before the release. That commit would contain the #[clippy::version = nightly] attributes. But we don't want them in beta (or stable) branch.
So to fix that, we (the person doing the syncs) would have to do an extra version replacement during the sync 2 weeks before the release. Or maybe doing so before every sync would be even better. If this needs to be done during sync, we need to automate it with a cargo dev command. (Haven't looked at the changes, you might've already done this)
However checking this in CI is tricky. We could check in the Rustup PR, that there are no clippy::version = nightly attributes in the codebase. But I'm afraid that's not enough. This check would have to run in the Rust repo when doing the sync from Clippy->Rust. Otherwise, if the Clippy->Rust direction sync is delayed and there is time in between the Rust->Clippy sync and the Clippy->Rust sync, a new lint might be added, rendering the check on the Rustup PR in the Clippy repo useless.
While writing this, we could also get around this: Add a test to tests/ that only runs if RUSTC_TEST_SUITE (opposite to the version check tests), that checks the codebase for clippy::version = nightly. Then one would be forced to update the versions during the Clippy->Rust sync.
That sounds good, here's an example output
running 1 test
test no_nightly_versions_in_rust_repo ... FAILED
failures:
---- no_nightly_versions_in_rust_repo stdout ----
clippy_lints/src/doc/mod.rs:85: doc_link_code has #[clippy::version = "nightly"]
clippy_lints/src/doc/mod.rs:451: doc_overindented_list_items has #[clippy::version = "nightly"]
clippy_lints/src/loops/mod.rs:718: manual_slice_fill has #[clippy::version = "nightly"]
clippy_lints/src/matches/mod.rs:975: manual_ok_err has #[clippy::version = "nightly"]
clippy_lints/src/mem_replace.rs:46: mem_replace_option_with_some has #[clippy::version = "nightly"]
clippy_lints/src/methods/mod.rs:4465: io_other_error has #[clippy::version = "nightly"]
clippy_lints/src/methods/mod.rs:4440: manual_contains has #[clippy::version = "nightly"]
clippy_lints/src/methods/mod.rs:4322: manual_repeat_n has #[clippy::version = "nightly"]
clippy_lints/src/methods/mod.rs:4373: return_and_then has #[clippy::version = "nightly"]
clippy_lints/src/methods/mod.rs:4345: sliced_string_as_bytes has #[clippy::version = "nightly"]
clippy_lints/src/methods/mod.rs:4413: unbuffered_bytes has #[clippy::version = "nightly"]
clippy_lints/src/methods/mod.rs:4295: useless_nonzero_new_unchecked has #[clippy::version = "nightly"]
clippy_lints/src/precedence.rs:28: precedence_bits has #[clippy::version = "nightly"]
clippy_lints/src/single_option_map.rs:12: single_option_map has #[clippy::version = "nightly"]
clippy_lints/src/unnecessary_semicolon.rs:9: unnecessary_semicolon has #[clippy::version = "nightly"]
clippy_lints/src/unneeded_struct_pattern.rs:9: unneeded_struct_pattern has #[clippy::version = "nightly"]
clippy_lints/src/deprecated_lints.rs: option_map_or_err_ok has #[clippy::version = "nightly"]
thread 'no_nightly_versions_in_rust_repo' panicked at tests/lint-definitions.rs:34:5:
assertion failed: !failed
:umbrella: The latest upstream changes (possibly d28d2344d000aa96bef729cf408731f952f71fb0) made this pull request unmergeable. Please resolve the merge conflicts.
IIUC, this PR would help prevent wrong version errors such as #14653 #14654, right?
IIUC, this PR would help prevent wrong version errors such as #14653 #14654, right?
Yep, that's the plan
Removed changes to the current versions from this PR, they can be done separately
Great @Alexendoo! I went through the last few versions to check for further version errors and found around 10 in total, so this PR is really needed if the versions are meant to be correct and not just rough indications with a margin of +/- 2.
:umbrella: The latest upstream changes (possibly 54aa120f18e4fafc8c47ab1acf08d76d4d8e6bff) made this pull request unmergeable. Please resolve the merge conflicts.
:umbrella: The latest upstream changes (possibly 94cfebb397e509d283f092504c34fa26638b3e75) made this pull request unmergeable. Please resolve the merge conflicts.
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.
Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.
:umbrella: The latest upstream changes (possibly f3c020cd55c3f14ea2dc6fbca4188e623ad72dd2) made this pull request unmergeable. Please resolve the merge conflicts.
Why are you removing the versions from renames? That's still useful for when those get added to the lints page.
The rename versions are not displayed anywhere including the lints page, almost all of them leave it blank
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.
Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.