"unconstrained generic constant" doesn't make sense with `generic_const_exprs`

I tried this code:

// One crate
pub struct Tree<const C: u32> {}

impl<const C: u32> Tree<C> {
    pub fn verify()
    where
        [(); C as usize]:,
    {
    }
}

pub struct TreeEntry;

impl TreeEntry {
    pub const S: usize = 8;
}

// Another crate
Tree::<{ TreeEntry::S.ilog2() }>::verify();

I expected to see this happen: It should compile and it actually does when in the same crate

Instead, this happened:

error: unconstrained generic constant
   --> crates/subspace-verification/src/lib.rs:242:5
    |
242 |     Tree::<{ TreeEntry::S.ilog2() }>::verify();
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
note: required by a bound in `ab_merkle_tree::balanced_hashed::Tree::<C>::verify`
   --> crates/shared/ab-merkle-tree/src/balanced_hashed.rs:248:14
    |
246 |     pub fn verify()
    |            ------ required by a bound in this associated function
247 |     where
248 |         [(); C as usize]:,
    |              ^^^^^^^^^^ required by this bound in `Tree::<C>::verify`
help: try adding a `where` bound
    |
200 |     [(); C as usize]:
    |     +++++++++++++++++

Suggestion is incorrect: it suggests to add bound on generic constant C, but in the scope where it is used there is no such constant, only Record::S.ilog2(). Adding bound with Record::S.ilog2() doesn't help with this either. Using explicit numeric literal avoids the issue.

I looked at a few potentially relevant issues, but nothing seems to match this exactly.

I'd love to see more work happening around generic_const_exprs, it is such an amazing capability!

Meta

rustc --version --verbose:

rustc 1.88.0-nightly (2da29dbe8 2025-04-14)
binary: rustc
commit-hash: 2da29dbe8fe23df1c7c4ab1d8740ca3c32b15526
commit-date: 2025-04-14
host: x86_64-unknown-linux-gnu
release: 1.88.0-nightly
LLVM version: 20.1.2

Reproduce the issue with the two-crate generic_const_exprs example and the rustc 1.88.0-nightly version shown. Compare the same expression within one crate against the cross-crate call, focusing on the diagnostic and suggested bound. Done means the cross-crate case is handled consistently and the emitted suggestion is valid.