Ensure that feature stabilizations are for the current version

[est31]

It's a common phenomenon that feature stabilizations don't make it into a particular release, but the version is still inaccurate. Often this is caught in the PR, but it can also require subsequent changes to adjust/correct the version, e.g.:

• float_bits_conv made it into 1.20 #43315
• Fix stabilization version for bindings_after_at #89605
• fix since field version for termination stabilization #95452
• Update pin_static_ref stabilization version. #94186
• Fix stabilization version of Ipv6Addr::to_ipv4_mapped #97337

This PR adds checking to ensure that a stabilization is always for the current release: it makes tidy determine a git "base commit" for the given change, and then compares the list to that base commit. That way, tidy knows the features that have stabilized, and can compare them to the current version.

Currently, this is implemented for lang features only, but with some engineering it can be extended to library features as well.

Note: currently the PR includes a mock stabilization meant to showcase how the PR works. I will remove it once the bot issues the expected complaint.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

    Checking rustc_query_impl v0.0.0 (/checkout/compiler/rustc_query_impl)
    Checking rustc_passes v0.0.0 (/checkout/compiler/rustc_passes)
    Checking rustc_ast_lowering v0.0.0 (/checkout/compiler/rustc_ast_lowering)
    Checking rustc_save_analysis v0.0.0 (/checkout/compiler/rustc_save_analysis)
error[E0609]: no field `fn_align` on type `&Features`
     |
     |
1570 |                     if let (Target::Fn, false) = (target, self.tcx.features().fn_align) {
     |
     |
     = note: available fields are: `declared_lang_features`, `declared_lib_features`, `active_features`, `abi_thiscall`, `abi_unadjusted` ... and 176 others
For more information about this error, try `rustc --explain E0609`.
error: could not compile `rustc_passes` due to previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `rustc_passes` due to previous error

[Mark-Simulacrum]

FWIW, there's been some recent discussion about improving this to be automatic (https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/libs.20stabilization.20placeholder).

I've not looked at the code here, but I think the effect of the proposal in Zulip would be that we just need to make sure folks are using the magic for any new stabilizations; I'm not sure we need a tidy check for that though (or how feasible it is, if we're intending to backport stabilizations for some reason, though we shouldn't do that).

[est31]

interesting, I guess that approach is even better. Closing, but I might open another PR with the implementation of that suggestion.