https://github.com/rust-lang/rust/blob/90b65889799733f21ebdf59d96411aa531c5900a/compiler/rustc_hir_analysis/src/check/wfcheck.rs#L1502-L1505
This normalize call is a noop in the new solver. I think we should just slap a deeply_normalize there instead and add a FIXME that we should check where-clauses for WF pre normalization. Though separately, we should do a crater run to see the impact of not normalizing here. The below breakage simply seems desirable to me and idk if there's non desirable breakage
rows 609 and 610, modcholesky crater logs, godbolt
pub struct View<A>(A);
pub trait Data {
type Elem;
}
impl<'a, A> Data for View<&'a A> {
type Elem = A;
}
pub fn repro<'a, T>()
where
<View<&'a T> as Data>::Elem: Sized,
{
}
this breakage looks intended, in the sense that you'd get the same error on the old solver with only the Data bound without looking into the associated type
https://github.com/rust-lang/rust/blob/90b65889799733f21ebdf59d96411aa531c5900a/compiler/rustc_hir_analysis/src/check/wfcheck.rs#L1502-L1505
This normalize call is a noop in the new solver. I think we should just slap a
deeply_normalizethere instead and add a FIXME that we should check where-clauses for WF pre normalization. Though separately, we should do a crater run to see the impact of not normalizing here. The below breakage simply seems desirable to me and idk if there's non desirable breakagerows 609 and 610,
modcholeskycrater logs, godboltthis breakage looks intended, in the sense that you'd get the same error on the old solver with only the
Databound without looking into the associated type