Non-`'static` lifetime inferred for return position `impl Trait` (fixed in beta)

[ecstatic-morse]

On beta and nightly, the following code is correctly rejected since the impl Trait in return position gets 'static by default. However, on the current stable (1.38), it was wrongfully accepted. Replacing the trait object with another type seems to make the error appear on all versions.

Playground

use std::any::Any;

fn drain_dyn(v: &mut Vec<Box<dyn Any>>) -> impl Iterator<Item = Box<dyn Any>> {    
    v.drain()
}

This has already been fixed, so I'm not sure what the procedure is here. Observed in the crater run for 1.39 (#64962) and split out from #65527.

[Mark-Simulacrum]

Nominating for compiler team -- I suspect we just want to close this, but wanted to raise this at least so we're aware. It's possible we can track down the fix and backport to stable, though at this point we're at 4 weeks out so it may not be worth it.

[Centril]

I'm betting this is #62849 (this should be checked and then that PR should be stable-nominated).

[pnkfelix]

@jonas-schievink my understanding, based on the description, is that this is stable-to-stable regression that already has a fix that has ridden the trains to beta, not a stable-to-beta regression.

• Update: that understanding was flawed, as you can see from my comments that follow.

[pnkfelix]

(unless the tagging as a regression is due to it being a user observable change in behavior from "stable rust". I need to track down what the behavior of this has been over time...)

[pnkfelix]

If this is "just" a change in observable behavior, where we had "always" accepted the code previously, then I don't think there is any motivation to do a backport-to-stable; there is no need to speed up how soon the change lands. (If anything, we should be trying to evaluate the fallout from the change, and deciding if we need to do a revert of the change on beta. But I think the crater report that preceded this bug being filed is telling us that such a reversion is not necessary...)

[pnkfelix]

Okay, so it looks like if you revise the test to work in older versions of Rust (by using Box<Trait> instead of Box<dyn Train> and fixing the call to drain to pass a range), then this has been accepted by the compiler ever since impl Trait in return position was stabilized, back in Rust 1.26.0.

So then the question is whether this is an old known bug in impl Trait; if not, then the question is if wheteher this fallout from whatever change injected this (presumably PR #62849) is acceptable/desirable.

[pnkfelix]

I think resolving the questions in the previous comment is part of T-lang, not just T-compiler. Tagging with T-lang and leaving nomination tag in place for discussion at T-lang meeting.