implied bounds from projections in impl header can be unsound

[aliemjay]

A variant of #98543 that has a different failure path and thus is not fixed by #99217. cc @lcnr

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=da2da1d93c1e2c99c640000a78e9a80f

trait Trait {
    type Type;
}

impl<T> Trait for T {
    type Type = ();
}

trait Extend<'a, 'b> {
    fn extend(self, s: &'a str) -> &'b str;
}

impl<'a, 'b> Extend<'a, 'b> for <&'b &'a () as Trait>::Type
where
    for<'what, 'ever> &'what &'ever (): Trait,
{
    fn extend(self, s: &'a str) -> &'b str {
        s
    }
}

fn main() {
    let y = <() as Extend<'_, '_>>::extend((), &String::from("Hello World"));
    println!("{}", y);
}

@rustbot label C-bug I-unsound T-types A-implied-bounds A-associated-items

[lcnr]

ah, that's fun 👍

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

[lcnr]

@rustbot claim

[lcnr]

To fix this we pretty much have to add explicit WellFormed predicates to the predicates of impls which results in solver cycles until we've made all trait predicates coinductive.

See this document for more info https://hackmd.io/_F7hq8ldSr-PuqudZ1A-nA#new-trait-solver-cycles

This is blocked on stabilizing the new trait solver.

[Neutron3529]

Seems #25860, an ancient issue.

[lcnr]

While these issues have a similar root cause, the way it is exploited differs. The root cause is that we do not explicitly track implied bounds of impls and functions, instead assuming that they'll have to be proven when checking that the used types are well-formed at the call-site.

This assumption is invalidated in #25860 by subtyping the function pointers before calling it. In this issue we only check that the normalized impl header is well-formed and "normalize away" the type requiring the implied bound when using the impl, but cannot do so due to the where-bound while computing the implied bounds used by the impl.