Inference hazard due to lazy alias relate: Break it in the old solver?

[compiler-errors]

Lazy alias relate causes us to no longer (incompletely) infer alias args when we don't normalize aliases to infer vars. That causes this code to (rightfully, IMO) fail:

trait Foo {
    type Assoc<'a>;
}

fn foo<'a, T: Foo>(_: <T as Foo>::Assoc<'a>) {}

fn test<'a, T: Foo>() {
    let y: fn(<T as Foo>::Assoc<'a>) = foo;
}

I'd like to prevent this from being more of an issue, but nothing comes to mind for a good scheme to weaken this inference in the old solver. Ideas?

[compiler-errors]

(cannot remember if this is already tracked as an issue lol)

[lcnr]

not sure 😅 doesn't really seem like it... definitely a known issue and I don't see how we can easily change this behavior in the old solver

[lcnr]

I'd like to prevent this from being more of an issue, but nothing comes to mind for a good scheme to weaken this inference in the old solver. Ideas?

Thinking about this, esp wrt to the actual breakage to bevy-ecs bevyengine/bevy#18840, I expect that pretty much all use of this will be due to a function call.

So instead of trying to detect cases where the old solver incorrectly relates arguments for higher ranked projections, we could instead future compat lint function definitions which can result in such patterns.

I think the link should fire if:

• the function has a higher ranked alias in its signature
• this alias references a generic parameter T which is never mentioned in a rigid/constraining position in the signature
• depending on how often the lint triggers with that, we could also restrict the lint to cases where it's more likely to cause issues
  • only consider a parameter T if its used as the self type of an alias (as these aliases are definitely ambiguous)
  • do not consider a parameter T if its referenced by a where-clause (of which it is not the self parameter)

[compiler-errors]

So I'd like to note that the only reason that Bevy was triggering this bug was b/c of a redundant where clause:

trait SystemInput {
    type Param<'a>;
    type Inner<'a>;

    fn wrap(x: Self::Inner<'_>) -> Self::Param<'_>;
}

struct World;

fn run<In: SystemInput, Out>(
    s: fn(In::Param<'_>, &mut World) -> Out,
    world: &mut World,
    input: In::Inner<'_>,
) -> Out
/// !!!!!!!!!! ///
where
    fn(In::Param<'_>, &mut World) -> Out: Fn(In::Param<'_>, &mut World) -> Out,
/// !!!!!!!!!! ///
{
    fn call_inner<In: SystemInput, Out>(
        mut f: impl FnMut(In::Param<'_>, &mut World) -> Out,
        input: In::Inner<'_>,
        world: &mut World,
    ) -> Out {
        f(In::wrap(input), world)
    }
    call_inner(s, input, world)
}

Without it, we end up confirming an FnPtrCandidate, which ends up normalizing the signature after its binder is instantiated, meaning that this incompleteness doesn't apply:

https://github.com/rust-lang/rust/blob/b8c54d6358926028ac2fab1ec2b8665c70edb1c0/compiler/rustc_trait_selection/src/traits/select/confirmation.rs#L999-L1005

I'm not totally certain how common this case is, though, so I still think the major place this happens is FnDef -> FnPtr coercions like the example I shared originally, and possibly params like F: Fn(T::Assoc<'a>).

[lcnr]

I don't see a where-clause in the diff in bevyengine/bevy#18840 🤔 am I missing something that's hidden by the macro?

[compiler-errors]

No I was mistaken, it wasn't fn(): FnMut bounds, but the multiple &mut F: FnMut bounds in the impl generated.

[lcnr]

Also impacts minijinja

trait Filter<Args> {}
trait FunctionArgs<'a> {
    type Output;
}

fn callee<F, Args>(_: F)
where
    Args: for<'a> FunctionArgs<'a>,
    F: Filter<Args>,
    F: for<'a> Filter<<Args as FunctionArgs<'a>>::Output>,
{
}

fn caller<F, Args>(x: F)
where
    Args: for<'a> FunctionArgs<'a>,
    F: Filter<Args>,
    F: for<'a> Filter<<Args as FunctionArgs<'a>>::Output>,
{
    callee(x)
}