generic_const_exprs well formed requirement break on crate bondary

[louwenus]

Code

// in crate A:
#![feature(generic_const_exprs)]

pub trait Conf: {
    const LAYER_COUNT: usize;
}
pub trait Buggy: {
    const TEST: u8 = 0;
}
impl<T: Conf> Buggy for T where [(); Self::LAYER_COUNT]: {}

//in crate B
use A::{Buggy, Conf};
struct UserStruct {}
impl Conf for UserStruct {
    const LAYER_COUNT: usize = 0;
}

fn main() {
    UserStruct::TEST;
}

Current output

error[E0275]: overflow evaluating the requirement `[(); A::::{impl#0}::{constant#0}] well-formed`
  |
  = note: required for `UserStruct` to implement `Buggy`

For more information about this error, try `rustc --explain E0275`.

Desired output

error: evaluating Well formedness require the generic_const_exprs feature to be activated in crate B
= note: required for `UserStruct` to implement `Buggy`

Rationale and extra context

I don't know if this should be a bug report instead, but the current workaround of activating the feature in the client crate (B in this exemple) is good enough for me: I just wish I got to it sooner, I passed hours minimizing the error before understanding it was because of a crate boundary, as googling the error linked to self referential constraint error, which is obviously not the case there

Other cases

Rust Version

rustc 1.91.0-nightly (7d82b83ed 2025-08-06)
binary: rustc
commit-hash: 7d82b83ed57d188ab3f2441a765a6419685a88a3
commit-date: 2025-08-06
host: x86_64-unknown-linux-gnu
release: 1.91.0-nightly
LLVM version: 21.1.0

Anything else?

the fact that this workaround exists is also discussed in #141492 I however did not found a bug report for this specific case, please correct me if I am wrong

PS: what is a good practice for bug report when several crates need to be involved for the bug to occur ? I can provide a link to a github with the whole env set up if needed/better