Implied bounds by associated types as function parameters are inconsistent in an unsound way.

[steffahn]

Taking a simple trait

trait Trait {
    type Type;
}

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

the type <&'a &'b () as Trait>::Type as a function argument gives rise to a 'a: 'b bound, as can be demonstrated by e.g.

fn f<'a, 'b>(s: &'b str, _: <&'a &'b () as Trait>::Type) -> &'a str {
    s
}

However, this bound is apparently not really enforced. I suppose the compiler “simplifies” such a function to f<'a, 'b>(s: &'b str, _: ()) -> &'a str for the caller? So

fn main() {
    let x = String::from("Hello World!");
    let y = f(&x, ());
    drop(x);
    println!("{}", y);
}

compiles fine and produces UB. (playground)

Another implication of the same kind of issue is that a function like

type Type<T> = <T as Trait>::Type;

fn g<'a>(_: Type<&'a ()>) -> &'a str {
    ""
}

fails to compile with a weird error message.

   Compiling playground v0.0.1 (/playground)
error[E0581]: return type references lifetime `'a`, which is not constrained by the fn input types
  --> src/lib.rs:11:30
   |
11 | fn g<'a>(_: Type<&'a ()>) -> &'a str {
   |                              ^^^^^^^

For more information about this error, try `rustc --explain E0581`.

The error code 581 only talks about fn-pointer types (playground)

@rustbot label T-compiler, A-lifetimes, A-typesystem, A-traits, A-associated-items, I-unsound

Originally discovered in a discussion on URLO.

[ecstatic-morse]

Another dupe of #25860?

[Cyborus04]

Another dupe of #25860?

I knew I had seen something like this before, I was just searching through my history to see if I could find it haha

[steffahn]

Another dupe of #25860?

No, not a dupe of #25860. This issue has nothing to do with variance.

Edit: To be clear, the issues are certainly related and I wouldn't be surprised if a fix of #25860 also fixes this issue.

[danielhenrymantilla]

I can confirm this doesn't have to do with variance:

trait Trait { type T; }
impl Trait for &'_ &'_ () { type T = (); }

/// Invariant
struct Inv<'lt>(fn(&()) -> &mut &'lt ());

fn transmute_lt<'src : 'src, 'dst : 'dst> (
    s: Inv<'src>,
    // `'src : 'dst` i.e. `'src ⊇ 'dst`
    _dst_implied_smaller: <&'dst &'src () as Trait>::T,
    // `'dst : 'src` i.e. `'dst ⊇ 'src`
    _dst_implied_greater: <&'src &'dst () as Trait>::T,
) -> Inv<'dst> {
    // => `'src = 'dst` => does typecheck
    s
}

/// Typechecks!
fn enlarge<'short, 'long : 'short> (
    it: Inv<'short>,
) -> Inv<'long>
{
    // signature of transmute_lt:
    let f: fn(Inv<'short>, (), ()) -> Inv<'long> = transmute_lt::<'short, 'long>;
    f(it, (), ())
}

• Playground

[steffahn]

To demonstrate the point that this has nothing to do with variance or double-references, here's the same thing with a custom invariant struct

struct S<'a: 'static>(*mut &'a ());

fn f<'a>(s: &'a str, _: <S<'a> as Trait>::Type) -> &'static str {
    s
}

// same main function…

(playground)

[steffahn]

The same bug can (not too surprisingly) also be used to write trait implementations that (unsoundly) have additional implied bounds available in the method body. E.g.

trait Trait<Dummy> {
    type Type;
}

impl<T, Dummy> Trait<Dummy> for T {
    type Type = T;
}

struct StrRef<'a>(&'a str);

impl<'a, 'b> From<&'a str> for StrRef<'b> {
    fn from(s: <&'a str as Trait<&'b &'a str>>::Type) -> StrRef<'b> {
        Self(s)
    }
}

fn main() {
    let x = String::from("Hello World!");
    let y = StrRef::from(x.as_str()).0;
    drop(x);
    println!("{}", y);
}

(playground)