Const generic type inference works when it should not

[nazar-pc]

I tried this code:

#![expect(incomplete_features, reason = "generic_const_exprs")]
#![feature(generic_const_exprs)]

pub fn compute_root_only<const N: u64>() -> u64
where
    [(); N.ilog2() as usize]:,
{
    N
}

#[test]
fn test() {
    test_impl::<99>();
}

#[cfg(test)]
fn test_impl<const N: u64>()
where
    [(); N.ilog2() as usize]:,
{
    // Const generic is inferred, but it shouldn't be!
    assert_eq!(compute_root_only(), N);
}

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=1b2f4edef4886032e1f9391f671112f4

I expected to see this happen:

error[E0284]: type annotations needed
  --> src/lib.rs:22:16
   |
22 |     assert_eq!(compute_root_only(), N);
   |                ^^^^^^^^^^^^^^^^^ cannot infer the value of the const parameter `N` declared on the function `compute_root_only`
   |
note: required by a const generic parameter in `compute_root_only`
  --> src/lib.rs:4:26
   |
4  | pub fn compute_root_only<const N: u64>() -> u64
   |                          ^^^^^^^^^^^^ required by this const generic parameter in `compute_root_only`
help: consider specifying the generic argument
   |
22 |     assert_eq!(compute_root_only::<N>(), N);
   |                                 +++++

Instead, this happened: It compiles successfully 🤯

The key thing is where bound. If it is simplified to something simpler like this:

where
    [(); N]:,

Then I do get expected compiler error.

This is basically a miscompilation, compiler should not pick arbitrary matching where bound from the context of the caller to infer types of the called function unless corresponding constant is used explicitly.

Meta

rustc --version --verbose:

rustc 1.89.0-nightly (cdd545be1 2025-06-07)
binary: rustc
commit-hash: cdd545be1b4f024d38360aa9f000dcb782fbc81b
commit-date: 2025-06-07
host: x86_64-unknown-linux-gnu
release: 1.89.0-nightly
LLVM version: 20.1.5

[workingjubilee]

... sorry, trying to understand this report. Isn't the inference correct?

[nazar-pc]

It is correct here, but I didn't specify the value of const N for compute_root_only() and this is a completely arbitrary guess, there is no direct connection between two functions.

This is the first ever instance where I see a behavior like this. If this was intentional, I would have expected for [(); N]:, to have the same effect and from there probably non-const generics to be inferred the same way too, but none of that is actually the case except for this interesting special case.

[fmease]

Smaller:

#![feature(generic_const_exprs)]

fn f<const N: usize>() where [(); N as _]: {}
fn g<const N: usize>() where [(); N as _]: { f() }

Reproduces when the where-clauses match 100% and if the const parameter is involved "non-trivially" (N would be "trivial"; N as _ / std::convert::identity(N) would be "non-trivial" ((N) crashes but that's been reported already)).