Confusing error msg for lifetime mismatch (possibly a bug in lifetime inference as well)

[daniel-vainsencher]

Originally opened in wrong repository (rfcs) as [0].

The problem is demonstrated by compiling [1]. I can work around the problem by using [2](first half of the diff is relevant to this problem, second part not so much), or by patching ndarrays to give parameters of binary operators distinct lifetime parameters.

A few problems here:

1. The basic error message is not very clear:

src/lib.rs:30:28: 30:38 error: cannot infer an appropriate lifetime for borrow expression due to conflicting requirements [E0495]
src/lib.rs:30         let delta = data - &self.mean;
<arrow pointing at &self.mean>

Lifetime of what expression cannot be inferred? What are the conflicting requirements? as someone with an only approximate mental model of lifetimes (i.e., a typical rust user) this is not helping me a lot to solve the problem nor to learn about lifetimes.

1. The compiler suggests something that doesn't work. I don't expect suggestions to always work, but maybe its worth pointing this case out so that the suggestion can be improved or made conditional.

src/lib.rs:27:5: 38:6 help: consider using an explicit lifetime parameter as shown: fn next_value<'a>(&'a mut self, data: &'a V, weight: f64)
src/lib.rs:27     pub fn next_value(&mut self, data : &V, weight : f64) {

1. @bluss suggested that rustc should be able to infer for the self and data borrows the intersection of their lifetimes, hence this should not be happening at all. I have no idea.
2. The work around in [2] suggested by @bluss leaves me even more confused. I can change the lifetime of data by ... (what is that, actually, reborrowing it?), and then the borrow of self is ok? But if that's a good way to go about things, maybe the compiler should suggest this method sometimes.

Anyway, if any part of the documentation (error: no extended information for [E0495]) can enlighten me, pointers accepted gladly.

[0] rust-lang/rfcs#1523 (comment)
[1] daniel-vainsencher/online_weighted_stats@8f9cf03
[2] daniel-vainsencher/online_weighted_stats@0bfc04d

@bluss said: I think this is a representative minimization.
https://play.rust-lang.org/?gist=59e6b8c113e4e7eda1fe&version=stable

I get completely different error messages at that playground link, btw,
though still somewhat confusing: it is not clear why the block suffix does
not suffice, seems to cover the relevant part of the anonymous lifetime.

[bluss]

This is an error that appears when you call: input + &local but does not appear with the equivalent desugaring Add::add(input, &local).

[Ryman]

Should the definition of Add not be more like this (note the extra lifetime 'b) or is that impossible in the real implementation?

[daniel-vainsencher]

That is a good fix to that particular library (already merged). This about
the compilers feedback/rejection.

Should the definition of Add not be more like this
https://play.rust-lang.org/?gist=0d840680345dfa99c4e4&version=stable
(note the extra lifetime 'b) or is that impossible in the real
implementation?

—
Reply to this email directly or view it on GitHub
#32008 (comment).

[arielb1]

We don't auto-reborrow when we don't have a known target type. Maybe we should use subtyping in overloaded operator matching?

Lifetime errors sucking is a known issue.

[arielb1]

Actually, in this case the lifetime error wasn't totally stupid. The compiler thinks that the lifetimes of the references must be related (this is a bug that should be fixed), and it proposes that you force them to be equal (in fact, an 'a: 'b bound is enough but the error proposes to unify the lifetimes. why?).

Of course, with the problem being that the lifetimes are related, just satisfying that leads to another error down the line. Type errors tend to be like that.

[Rufflewind]

Ran into this (Playground) just now. It’s weird that add works just fine …

use std::ops::Add;

struct Foo;

impl<'a> Add<&'a Foo> for &'a Foo {
    type Output = Foo;
    fn add(self, rhs: &'a Foo) -> Self::Output { Foo }
}

fn foo<'a, 'b>(x: &'a Foo, y: &'b Foo) -> Foo {
    x + y
 // ^^^^^ cannot infer an appropriate lifetime for lifetime parameter `'a`
 //       due to conflicting requirements
}

fn main() { }

[eddyb]

Duplicate of #45425 (thanks, @bluss!).