ICE, regression from stable/beta -> nightly: var types encountered in super_relate_consts when trait bound not satisfied

[sharnoff]

Regression from stable 1.66 / beta 1.67 -> nightly 1.68 (haven't bisected). Stable/beta correctly produce an error, nightly ICEs. I've also confirmed the behavior on the latest commit to master (9709a43, at time of writing).

Code

struct Foo<T, const N: usize> {
    array: [T; N],
}

trait Bar<const N: usize> {}

impl<T, const N: usize> Foo<T, N> {
    fn trigger(self) {
        self.unsatisfied()
        //   ^^^^^^^^^^^ expected location of type error (T: Bar<N> isn't satisfied)
        // Instead, nightly produces an ICE when
    }

    fn unsatisfied(self)
    where
        T: Bar<N>,
    {
    }
}

• playground link (nightly — ICE)
• playground link (beta — error as expected)
• playground link (stable — error as expected)

Compiler output (ICE text)

error: internal compiler error: /rustc/92c1937a90e5b6f20fa6e87016d6869da363972e/compiler/rustc_middle/src/ty/relate.rs:638:13: var types encountered in super_relate_consts: Const { ty: usize, kind: Infer(Var(_#0c)) } Const { ty: usize, kind: Param(N/#1) }

--- other text omitted ---

query stack during panic:
#0 [typeck] type-checking `<impl at bad.rs:7:1: 7:34>::trigger`
#1 [typeck_item_bodies] type-checking all item bodies
#2 [analysis] running analysis passes on this crate
end of query stack
error: aborting due to previous error

Setting RUST_BACKTRACE=1 produced the same output as above.

Preliminary investigation

I tried to dig into this, struggled to make sense of the typechecking code. I think the following is going on:

super_relate_consts is being called with the const params N for self (as the receiver of trigger) and self (as the receiver of unsatisfied). They should both have kind: Param(N/#1), but one of them has kind: Infer(_).

This only happens if the trait bound is not satisfied. If we add where T: Bar<N> to trigger, then the program compiles.

[BoxyUwU]

cargo-bisect-rustc seems to think this is caused by #106025 of which #105985 looks like the most plausible candidate since it touched type relation code which calls super_relate_consts without handling infer vars 🤔 cc @compiler-errors

[compiler-errors]

Ugh i'll fix it
@rustbot claim

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

[eddyb]

This is a bit weird, but I was able to come up with an alternative reduction (after EmbarkStudios/rust-gpu#987 hit it on nightly-2022-12-18 - we use a pinned nightly so this is mostly a coincidence):

struct Foo<const N: usize>;

trait Bar<const N: usize> {}

impl<const N: usize> Foo<N> {
    fn unsatisfied(self, _: impl Bar<N>) {}
}

// Before nightly-2022-12-23.
fn trigger_old() {
    Foo.unsatisfied(());
}

// After nightly-2022-12-23 (inclusive).
fn trigger_new<const N: usize>() {
    Foo::<N>.unsatisfied(());
}

I'm not sure why the inference variable vs const generic param makes a difference like that, but I wasn't able to combine the two reductions together. Also, the ICE query stack confirms the trigger_old/trigger_new split between nightly versions, even in the combined example.