const_evaluatable_checked can cause a stackoverflow

[lcnr]

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=6bdb59061285589534c53004561c978a

#![feature(const_generics, const_evaluatable_checked)]

fn q<T, const N: usize>(_: T) -> [u8; N + 1] {
    todo!()
}

fn supplier<T>() -> T {
    todo!()
}

fn catch_me<const N: usize>() where [u8; N + 1]: Default {
    let mut x = supplier();
    x = q(x);
}

causes

thread 'rustc' has overflowed its stack
fatal runtime error: stack overflow
error: could not compile `playground`

(it does ICE with incremental enabled, this is a different bug and tracked separately)

We end up referencing an inference variable in the value of said inference variable, causing an infinite type.
This should ordinarily be prevented by the occurs check. We either have a bug there or there is something else I have missed

[lcnr]

we can't use super_relate_consts for the occurs check with const_evaluatable_checked. We do not try to relate the substs here.

rust/compiler/rustc_middle/src/ty/relate.rs

Lines 579 to 588 in 4cbda82

	(
	ty::ConstKind::Unevaluated(a_def, a_substs, None),
	ty::ConstKind::Unevaluated(b_def, b_substs, None),
	) if tcx.features().const_evaluatable_checked => {
	if tcx.try_unify_abstract_consts(((a_def, a_substs), (b_def, b_substs))) {
	Ok(a.val)
	} else {
	Err(TypeError::ConstMismatch(expected_found(relation, a, b)))
	}
	}

[Nadrieril]

I was playing with this and turns out catch_me does not need to be generic (playground):

#![feature(const_generics, const_evaluatable_checked)]

fn q<T, const N: usize>(_: T) -> [u8; N + 1] {
    todo!()
}

fn supplier<T>() -> T {
    todo!()
}

fn catch_me() {
    let mut x = supplier();
    x = q(x);
}

[lcnr]

yeah, I wanted to first write q::<_, N> 😆 as it already broke without that the N is currently unnecessary