Recursive type usage in function with Const Generics causes ICE

[felix91gr]

This is a toy example I made in order to later make tests which run for T<const M: usize> with M=0..N.

#![feature(const_generics)]
#[allow(incomplete_features)]

struct Z<const N: i32>;

impl<const N: i32> Z<{N}> {

	fn fact() -> i32 {
		match N {
			k if k < 1 => 1,
			_ => Z::<{N - 1}>::fact()
		}
	}

}

This is the error I get:

error: internal compiler error: src/librustc/ty/subst.rs:651: const parameter `N/#0` (Const { ty: i32, val: Param(N/#0) }/0) out of range when substituting substs=[]

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:890:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Error notes:

• rustc 1.40.0-nightly (50f8aadd7 2019-11-07) running on x86_64-unknown-linux-gnu

• compiler flags: -C debuginfo=2 -C incremental --crate-type lib

---

Questions

I don't know if this kind of pattern is intended as part of the feature or in its future, but if not, I think it can be satisfied by using a procedural macro so that's probably alright.

The point of the pattern, as I mentioned at the beginning of the post, is to be able to test a particular generic type's implementation up to an arbitrary range of numeric constants. While implementing another project to help @varkor test the feature, I stumbled upon the problem of wanting to test hundreds of different constants, but having no way of doing so with say, a for loop over a range of constants. This is one way I thought of making it work.

Am I making the right decisions here? How should I go about testing hundreds of constants? Thanks :)

[felix91gr]

Note: another example that also panics.

I know, yes, expressions aren't yet supported as const parameters. But it has the same panic, which is WEIRD!

When I wrote this one, I thought "okay maybe inside a match statement, the compiler won't try things like (0 - 1) because the case when N: usize is 0 is already covered... and with exhaustiveness check it should know that N = 0 won't enter the second branch". But I must be wrong there, or otherwise how did it panic?

#![feature(const_generics)]
#[allow(incomplete_features)]

struct Z<const N: usize>;

impl<const N: usize> Z<{N}> {

	fn fact() -> i32 {
		match N {
			0 => 1,
			_ => Z::<{
				match N {
					0 => 0,
					_ => N - 1,
				}
			}>::fact()
		}
	}

}

Error:

error: internal compiler error: src/librustc/ty/subst.rs:651: const parameter `N/#0` (Const { ty: usize, val: Param(N/#0) }/0) out of range when substituting substs=[]

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:890:9

[hellow554]

Minified:

#![feature(const_generics)]

fn fact<const N: usize>() {
    fact::<{ N - 1 }>();
}

I'm pretty sure that I saw this ICE before, but I can't find it ;/

[varkor]

This is just a result of having an expression (N - 1) as a const generic argument. I don't actually think there's a canonical issue, though many of the issues are essentially the same. #60471 is the best tracking issue.

[Alexendoo]

No longer ICEs on the latest nightly

[felix91gr]

Oh, the new output is interesting. It probably needs to be monomorphized so that the compiler detects the infinite recursion. And then we could also write one that doesn't have infinite recursion :3

In order to force an error, a test function should suffice right?

[hellow554]

Oh, the new output is interesting

What do you mean?

[felix91gr]

I mean that I imagined it might detect that the function recurses infinitely onto itself. But I guess it reads it lazily, and lets monomorphization do the job of recursing the function? which would make a lot of sense to me.