'missing lifetime specifier' regression in protobuf-1.0.1

[brson]

As reported by crater, Rust 1.3 nightlies appear to have introduced a regression in lifetime elision, probably related to default trait bounds.

cc @nikomatsakis @nrc @pnkfelix

Nominating in hopes a fix for this will appear before 1.3 beta.

[eefriedman]

Reduces to:

trait T:'static {}
fn main() {
    fn _message_down_cast(_m: &T) -> &i8 {
        panic!()
    }
}

[eefriedman]

RFC 141 says that "a lifetime position is anywhere you can write a lifetime in a type". According to that rule, fn(m: &(Sized+'static)) -> &i8 is ambiguous because there are two lifetime positions in the input, and this isn't a bug.

On the other hand, I'm pretty sure that isn't actually what we want, so we need a more precise rule which specifies exactly what lifetimes qualify as a "lifetime position".

Other random observations: nightly accepts the following, but stable doesn't:

fn main() {
    type T<'a> = &'a &'a i8;
    fn s(m: T) -> &i8 { m }
    static S: i8 = 1;
    static S2: &'static i8 = &S;
    s(&S2);
}

Neither nightly nor stable accept the following:

fn main() {
    type T<'a> = &'a &'static i8;
    fn s(m: T) -> &i8 { m }
    static S: i8 = 1;
    static S2: &'static i8 = &S;
    s(&S2);
}

[arielb1]

I think I accidentally introduced the regression as part of #26667. The previous version ignored object lifetime bounds - I should have caught this. I think the root cause here is that lifetime elision wasn't updated to respect object bounds.

[brson]

@nikomatsakis Per irlo this seems to affect some crates. Is there any way we can get this fixed this week in time for beta, or if not sometime in the next cycle for a backport?

[brson]

cc @rust-lang/compiler

[nikomatsakis]

triage: P-high

[nikomatsakis]

Sorry, I dropped the ball on compiler triage, but trying to get that wagon back on track now. Anyway, I'll look at this.

[nikomatsakis]

Ah, yes, I remember this issue now. I think this relates to the discussion about '_, and this comment of mine in particular. Basically I agree with @eefriedman that technically there is no bug here -- rather, a bug was fixed. However, the behavior doesn't seem right nonetheless, for the reasons I argued on the thread. It seems to me that trait object lifetimes, which follow distinct defaulting rules, should not affect elision in quite the way they currently do.

[nikomatsakis]

To be more specific, I think the rule we want is that object lifetimes only affect the elision rules if they are written explicitly, and not if defaults are used. I have to investigate how easy that will be to implement.