Adding Copy impl to type causes lifetime errors

[bkoropoff]

Code

Playpen link

#[derive(Clone)]
// Uncommenting the next line causes an error
//#[derive(Copy)]
struct Path<'a:'b, 'b> {
    x: &'a i32,
    tail: Option<&'b Path<'a, 'b>>
}

#[allow(dead_code, unconditional_recursion)]
fn foo<'a,'b,F>(p: Path<'a, 'b>, mut f: F)
                where F: for<'c> FnMut(Path<'a, 'c>) {
    foo(p, |x| f(x))
}

Error

<anon>:12:5: 12:8 error: cannot infer an appropriate lifetime for lifetime parameter `'a` due to conflicting requirements
<anon>:12     foo(p, |x| f(x))
              ^~~
<anon>:12:16: 12:20 note: first, the lifetime cannot outlive the lifetime 'c as defined on the block at 12:15...
<anon>:12     foo(p, |x| f(x))
                         ^~~~
<anon>:12:13: 12:14 note: ...so that trait type parameters matches those specified on the impl (expected `core::marker::Copy`, found `core::marker::Copy`)
<anon>:12     foo(p, |x| f(x))
                      ^
<anon>:11:54: 13:2 note: but, the lifetime must be valid for the lifetime 'a as defined on the block at 11:53...
<anon>:11                 where F: for<'c> FnMut(Path<'a, 'c>) {
<anon>:12     foo(p, |x| f(x))
<anon>:13 }
<anon>:12:5: 12:8 note: ...so that trait type parameters matches those specified on the impl (expected `core::ops::FnOnce<(Path<'_, 'c>,)>`, found `for<'c> core::ops::FnOnce<(Path<'a, 'c>,)>`)
<anon>:12     foo(p, |x| f(x))
              ^~~

Analysis

Notably, this does not occur with a trait like:

trait FakeCopy where Self: Clone {}

This smells like a bug to me, unless a language change introduced special treatment of Copy with regard to lifetimes.

[tomjakubowski]

An interesting quirk is that if you replace |x| f(x) with just f, it compiles fine with the Copy impl.

[bkoropoff]

cc @nikomatsakis

[pnkfelix]

@bkoropoff are you saying this used to work? Just curious what the original was.

[pnkfelix]

(Also it seems difficult if not impossible to satisfy the combination of 'a:'b and F: for <'c> ... 'c substituted for 'b .... ..... well I guess 'a of static would, but I don't know if we can deduce that.

[bkoropoff]

Yes, this used to work. This bug is affecting https://github.com/bkoropoff/rust-jlens

[bkoropoff]

It looks like this may have been introduced in 83ef304. Prior to this, checking for Copy bounds in expr_use_visitor was done via ty::type_moves_by_default, which creates a throw-away inference context before calling into trait selection. It now goes through the Typer; the impl of Typer for FnCtxt uses its own inference context. This causes region constraints introduced during trait selection for Copy to stick around, resulting in a seemingly inappropriate transitive constraint between the free 'c region within the closure body and 'a at the call site of foo.

[nikomatsakis]

@bkoropoff hmm good catch, sorry I let this slip through last week :( I'll try to pay it some attention now. The current code does not seem entirely wrong to me, though. I have to think this through a bit.