-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-'static
lifetime inferred for return position impl Trait
(fixed in beta)
#65582
Comments
'static
lifetime derived for return position impl Trait
(fixed in beta)'static
lifetime assigned to return position impl Trait
(fixed in beta)
'static
lifetime assigned to return position impl Trait
(fixed in beta)'static
lifetime inferred for return position impl Trait
(fixed in beta)
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. |
I'm betting this is #62849 (this should be checked and then that PR should be stable-nominated). |
@jonas-schievink
|
(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...) |
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...) |
Okay, so it looks like if you revise the test to work in older versions of Rust (by using So then the question is whether this is an old known bug in |
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. |
((Or maybe PR #62849 was always intended to be something that papers over #53613 and #51525, and it just didn't link to those tickets...?))
|
triage: P-high. Leaving nomination tag in place, for both T-compiler and T-lang. |
My two cents: This was anticipated fallout and yes we were fixing an old bug, basically. One thing I can't tell is whether there was fallout from this change in terms of things breaking in the wild? The comment by @ecstatic-morse suggests yes, but I couldn't immediately identify which things broke. |
According to #65527 (comment), soketto 0.2.0 broke |
Hey @twittner -- it looks like soketto 0.2.0 was affected by a recent bug fix that we did as part of the async-await work. Let us know if you need any help fixing the fallout. |
Looking more closely at this example, I am not convinced that this is related to #62849. If it were, I would expect an error message like
That said, this does really look like a bug fix -- I am pretty unclear on what fixed it, but I'm glad it got fixed! (Maybe we want to mark this as E-needs-test, even?) |
It also used to compile with use std::any::Any;
fn drain_dyn(v: &mut Vec<Box<dyn Any>>) -> impl Iterator<Item = Box<dyn Any>> {
v.drain(..)
} |
#62849 also had a full crater run, which should have caught this (although sometimes the crate lists are updated). |
Thanks @nikomatsakis! This was fixed by paritytech/soketto#1 and published as version 0.2.3 of soketto on 2019-08-19. |
(so was this in fact "fixed" aka injected by PR #63376 ? that might make sense... ) |
Heh; I've even left a comment wrt. soketto in that PR. 😆 |
OK, I'm going to close this as "expected bug fix with no further action needed". Thanks all! |
Note that the PR includes a text that seems like the same basic scenario: src/test/ui/object-lifetime/object-lifetime-default-dyn-binding-nonstatic1.rs |
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
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.
The text was updated successfully, but these errors were encountered: