Requiring version number to match upstream Rust version is unnecessary

[Mark-Simulacrum]

#6499 proposed locking the version number of clippy-the-cargo project to the version number of Rust. In practice, this causes some work for the release team during release week, and I'm not sure why it matters - to my knowledge, clippy isn't depended on by any projects outside the monorepo at rust-lang/rust and this repository, so the version number shouldn't meaningfully affect anyone. Can we remove the tests, at least? Cargo for example does not bump the version number in lockstep with the monorepo, for example, so it doesn't seem like this is all that necessary.

If there's some purpose to the version number then we can work on documenting the process to update in https://forge.rust-lang.org/release/process.html#bump-the-stable-version-number-t-6-days-friday-the-week-before, but it would be great to avoid that - we're hoping to eventually automate the release process pretty much start to finish, and the fewer files need to be edited (particularly relatively complex ones like Cargo.toml) the easier that will be.

[matthiaskrgr]

Could we just disable the test when running clippy tests from the rustc repo?
This way, there should be no failure when the rustc version is bumped in the rustc repo, but as soon as we do the next rustc->clippy sync (and bump the compiler version inside the clippy repo) the test would fail inside clippy CI and we'd be alerted to bump the version in our repo.

[Manishearth]

Yeah I think @matthiaskrgr's proposed plan is good here.

[Mark-Simulacrum]

That seems fine to me, anything that means we don't need to worry about it upstream basically solves my concerns. That said I'm not convinced you want this - but I'm not going to argue that, you know constraints better than I.

[Manishearth]

Yeah I don't think we really need this, but it's easy and convenient to have the version number somewhere in tree.

Clippy reports the rustc version on the CLI, and it would be kinda weird if that weren't somewhere in tree as well.

[Mark-Simulacrum]

Hm. I guess I don't see that as at all odd. But up to y'all.

[blyxyas]

Is this fixed by #6684?