fix inference variables leaking into HIR const literal lowering logic

[Human9000-bit]

Inference variables could leak into further const lowering logic

It ICEs when query system tries to cache lit_to_const() after its execution and panics, because inference variables are not hashable for some reason

Fixes #153524
Fixes #153525

[rustbot]

HIR ty lowering was modified

cc @fmease

[rustbot]

r? @dingxiangfei2009

rustbot has assigned @dingxiangfei2009.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 69 candidates
• Random selection from 16 candidates

[BoxyUwU]

r? BoxyUwU

[Human9000-bit]

I am sure this is pretty suboptimal error message. Could we think about a correct one?

[BoxyUwU]

this is interesting, ideally we to support cases where the expected type was unknown if the literal was explicitly typed, e.g. 1_i32 with an unknown expected type should work fine. The lit_to_const logic should already handle producing a lowered literal just fine in the presence of an unknown expected type so I think it's just a matter of actually allowing you to pass in nothing.

I think it would make sense to make the type in LitToConstInput optional and pass None in if there are inference variables in the expected type.

This should allow the following to compile:

#![allow(incomplete_features)]
#![feature(adt_const_params, min_generic_const_args, generic_const_parameter_types)]

fn main() {
    foo::<_, 2_i32>();
}

fn foo<T: ConstParamTy_, const N: T>() {}

[BoxyUwU]

because inference variables are not hashable for some reason

the thing here is that we don't want inference variables in query inputs/outputs. it's not that we can't hash them but that at a conceptual level it's not desirable to have them in queries.

an inference variable only makes sense as part of its InferCtxt so you'd have to pass that into the query too. but even if you do this a query with an inferctxt and infer vars is going to have a terrible cache hit rate (it'll basically never get a cache hit) so you really never want to have inference variables values of query arguments.

the typical thing you do for that use case is something called canonicalization (which we unfortunately dont really have many docs for other than this https://rustc-dev-guide.rust-lang.org/solve/canonicalization.html). an alternative solution for this ICE would be to make the lit_to_const query a canonical query but that doesn't seem worth it to me.

we dont actually want to handle infer vars inside the query and it would impose a perf overhead

[Human9000-bit]

Ah, that makes sense. Thank you for the explanation.

[rustbot]

Some changes occurred in match checking

cc @Nadrieril

Some changes occurred in rustc_ty_utils::consts.rs

cc @BoxyUwU

[BoxyUwU]

thx yeah this looks like the right solution to me now :3

View changes since this review

[rustbot]

This PR was rebased onto a different main 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.

[Human9000-bit]

Github is having a moment today

[BoxyUwU]

@bors r+ rollup

thx

[rust-bors]

📌 Commit 5113488 has been approved by BoxyUwU

It is now in the queue for this repository.

[Human9000-bit]

thank you for the review