Function rustc::traits::project::normalize_to_error[][src]

fn normalize_to_error<'a, 'gcx, 'tcx>(
    selcx: &mut SelectionContext<'a, 'gcx, 'tcx>,
    param_env: ParamEnv<'tcx>,
    projection_ty: ProjectionTy<'tcx>,
    cause: ObligationCause<'tcx>,
    depth: usize
) -> Normalized<'tcx, Ty<'tcx>>
🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

If we are projecting <T as Trait>::Item, but T: Trait does not hold. In various error cases, we cannot generate a valid normalized projection. Therefore, we create an inference variable return an associated obligation that, when fulfilled, will lead to an error.

Note that we used to return TyError here, but that was quite dubious -- the premise was that an error would eventually be reported, when the obligation was processed. But in general once you see a TyError you are supposed to be able to assume that an error has been reported, so that you can take whatever heuristic paths you want to take. To make things worse, it was possible for cycles to arise, where you basically had a setup like <MyType<$0> as Trait>::Foo == $0. Here, normalizing <MyType<$0> as Trait>::Foo> to[type error]would lead to an obligation of<MyType<[type error]> as Trait>::Foo. We are supposed to report an error for this obligation, but we legitimately should not, because it contains[type error]`. Yuck! (See issue #29857 for one case where this arose.)