unnormalized projections in writeback may contain infer vars

[lcnr]

If we have some <T as Id<?x>>::Assoc in hir typeck and the current impl normalizes that to T before writeback but is unable to infer ?x, then lazy norm would result in an inference error.

It seems like the following currently errors on stable, figure out why

trait Id<T: ?Sized> {
    type Assoc;
}

impl<T, U: ?Sized> Id<U> for T {
    type Assoc = T;
}

fn foo<T: Default>() -> T {
    <T as Id<_>>::Assoc::default()
}

[compiler-errors]

It seems like the following currently errors on stable, figure out why

This is expected behavior, because we resolve and encode the type of all hir::Ty nodes in the writeback results for foo, and _ is not the target of any diverging ! -> () fallback, it's not constrained to () during fallback or anything like that.

[compiler-errors]

I'm not sure if it's possible to come up with an example that has unconstrained infer vars in a projection in the new solver, without also having some "type annotations needed" error even on stable?

[compiler-errors]

Actually, nevermind! This happens with closure substs, specifically the tupled upvar subst:

fn main() {
    let mut x: Vec<_> = vec![];
    x.extend(Some(1i32).into_iter().map(|x| x));
}

[compiler-errors]

Also, pretty easy repro of the problem I guess:

trait Mk {
    type Assoc;
}
fn mk<T: Mk<Assoc = i32>>(t: T) -> T::Assoc {
    0
}

trait Bar {}
impl Bar for () {}
impl<T: Bar> Mk for T {
    type Assoc = i32;
}

fn main() {
    let mut x = Default::default();
    let y = mk(x);
    x = ();
}

[lcnr]

how does the second example work? don't we constrain T to () here so the type of y should be <() as Mk>::Assoc?

also confused about the first example 🤔 the projection is <<Map<std::option::IntoIter<i32>, [main::{closure#0} closure_substs=(unavailable) substs=[i16, extern "rust-call" fn((i32,)) -> i32, _#21t]]> as Iterator>::Item>, but shouldn't we infer _#21t(the closure upvars), to simply be () here?

[compiler-errors]

In both examples, we emit alias-relate goals instead of simply equating the projection ty to the infer-var of the let-bindings.

this is because we generalize the ty of the projection, since the let binding's infer var cannot name the projection type (it was created when the universe was still 0).

these alias-relate goals both hold trivially via the normalizes-to branch of the code, so we never end up relating the projection substs, and the infer var remains unconstrained in both examples.

that last part seems like it may be a slightly separate issue about alias-relate causing inference to be weaker... I'll file another issue when I wake up. edit: #13