Parse rustc version at compile time

[dtolnay]

This PR eliminates a couple awkward codepaths where it was not clear how the compiler should proceed if its own version number is incomprehensible.

rust/src/tools/clippy/clippy_utils/src/qualify_min_const_fn.rs

Line 385 in dab7156

panic!("`rustc_attr::StabilityLevel::Stable::since` is ill-formatted: `{CURRENT_RUSTC_VERSION}`, {err:?}")

rust/compiler/rustc_attr/src/builtin.rs

Line 630 in dab7156

let rustc_version = parse_version(CURRENT_RUSTC_VERSION, true).unwrap();

We can guarantee that every compiled rustc comes with a working version number, so the ICE codepaths above shouldn't need to be written.

[rustbot]

r? @compiler-errors

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[dtolnay]

👀 ⬆️

I don't fully understand how this works, but without this change, the PR does not compile. Hopefully it is okay.

error[E0277]: the trait bound `__CTX: rustc_session::HashStableContext` is not satisfied
   --> compiler/rustc_attr/src/builtin.rs:151:10
    |
151 |   #[derive(HashStable_Generic)]
    |            ^^^^^^^^^^^^^^^^^^
    |            |
    |            the trait `rustc_session::HashStableContext` is not implemented for `__CTX`
    |            in this derive macro expansion
    |
   ::: .cargo/registry/src/index.crates.io-6f17d22bba15001f/synstructure-0.13.0/src/macros.rs:94:9
    |
94  | /         pub fn $derives(
95  | |             i: $crate::macros::TokenStream
96  | |         ) -> $crate::macros::TokenStream {
    | |________________________________________- in this expansion of `#[derive(HashStable_Generic)]`
    |
    = note: required for `RustcVersion` to implement `HashStable<__CTX>`

[compiler-errors]

Yeah, this is fine.

[compiler-errors]

It's because of the HashStable_Generic derive on RustcVersion in rustc_session. If you really wanted to avoid this, you'd need to move that data structure from rustc_session to rustc_ast or derive it manually.

Deriving it manually may be easier since it's just a few u16s....?

[dtolnay]

Ah yes, this handwritten impl gets the job done: 0fc378a

// (in compiler/rustc_session/src/version.rs)

// Handwritten because #[derive(HashStable_Generic)] would generate a stricter
// `Ctx: rustc_session::HashStableContext` bound.
impl<Ctx> HashStable<Ctx> for RustcVersion
where
    Ctx: rustc_ast::HashStableContext,
{
    fn hash_stable(&self, hcx: &mut Ctx, hasher: &mut StableHasher) {
        self.major.hash_stable(hcx, hasher);
        self.minor.hash_stable(hcx, hasher);
        self.patch.hash_stable(hcx, hasher);
    }
}

But in the absence of any known downside of changing rustc_attr::HashStableContext, I think I would go for keeping the derived impl. I was not able to find any evidence of dyn HashStableContext in use anywhere, so I don't see any way that this change could bloat vtables, for example.

[compiler-errors]

r=me with or without nit

[compiler-errors]

It's because of the HashStable_Generic derive on RustcVersion in rustc_session. If you really wanted to avoid this, you'd need to move that data structure from rustc_session to rustc_ast or derive it manually.

Deriving it manually may be easier since it's just a few u16s....?

[dtolnay]

@bors r=compiler-errors

[bors]

📌 Commit b7debe3 has been approved by compiler-errors

It is now in the queue for this repository.