Stream: t-compiler

Topic: static lifetime in impl trait #65582


nikomatsakis (Oct 24 2019 at 20:26, on Zulip):

@Santiago Pastorino if you have a cargo bisect-rustc "up and going", do you think you could bisect something for me? :P

Santiago Pastorino (Oct 24 2019 at 20:26, on Zulip):

definitely

nikomatsakis (Oct 24 2019 at 20:26, on Zulip):

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e71ddd385cc651b1a62affcb301b812e

Santiago Pastorino (Oct 24 2019 at 20:26, on Zulip):

(deleted)

nikomatsakis (Oct 24 2019 at 20:26, on Zulip):

used to compile, now it doesn't

nikomatsakis (Oct 24 2019 at 20:26, on Zulip):

as it happens, this is a bug fix

nikomatsakis (Oct 24 2019 at 20:26, on Zulip):

but I'm curious what caused it :)

Santiago Pastorino (Oct 24 2019 at 20:27, on Zulip):

(deleted)

Santiago Pastorino (Oct 24 2019 at 20:27, on Zulip):

(deleted)

Santiago Pastorino (Oct 24 2019 at 20:28, on Zulip):

better have those removed :)

Santiago Pastorino (Oct 24 2019 at 20:29, on Zulip):
[santiago@galago niko-app (master)]$ cargo build
   Compiling niko-app v0.1.0 (/home/santiago/src/oss/niko-app)
error: cannot infer an appropriate lifetime
 --> src/main.rs:4:7
  |
3 | fn drain_dyn(v: &mut Vec<Box<dyn Any>>) -> impl Iterator<Item = Box<dyn Any>> {
  |                                            ---------------------------------- this return type evaluates to the `'static` lifetime...
4 |     v.drain(..)
  |     - ^^^^^
  |     |
  |     ...but this borrow...
  |
note: ...can't outlive the anonymous lifetime #1 defined on the function body at 3:1
 --> src/main.rs:3:1
  |
3 | / fn drain_dyn(v: &mut Vec<Box<dyn Any>>) -> impl Iterator<Item = Box<dyn Any>> {
4 | |     v.drain(..)
5 | | }
  | |_^
help: you can add a constraint to the return type to make it last less than `'static` and match the anonymous lifetime #1 defined on the function body at 3:1
  |
3 | fn drain_dyn(v: &mut Vec<Box<dyn Any>>) -> impl Iterator<Item = Box<dyn Any>> + '_ {
  |                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

error: could not compile `niko-app`.

To learn more, run the command again with --verbose.
[santiago@galago niko-app (master)]$ cargo +stable build
   Compiling niko-app v0.1.0 (/home/santiago/src/oss/niko-app)
warning: function is never used: `drain_dyn`
 --> src/main.rs:3:1
  |
3 | fn drain_dyn(v: &mut Vec<Box<dyn Any>>) -> impl Iterator<Item = Box<dyn Any>> {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(dead_code)]` on by default

    Finished dev [unoptimized + debuginfo] target(s) in 0.61s
[santiago@galago niko-app (master)]$
Santiago Pastorino (Oct 24 2019 at 20:29, on Zulip):

at least I can reproduce what you're saying :)

Santiago Pastorino (Oct 24 2019 at 20:41, on Zulip):

bisector is running, going to let you know when I have results

Santiago Pastorino (Oct 24 2019 at 20:43, on Zulip):

@nikomatsakis how old this problem is supposed to be? or no idea really?

Santiago Pastorino (Oct 24 2019 at 20:45, on Zulip):

well according to my tests should be between nightly and stable :)

Santiago Pastorino (Oct 24 2019 at 21:12, on Zulip):

@nikomatsakis had to leave but the tool even the master version is not working correctly

nikomatsakis (Oct 24 2019 at 21:12, on Zulip):

that example compiles successfully on stable

Santiago Pastorino (Oct 24 2019 at 21:12, on Zulip):

will check it out and let you know when I can

nikomatsakis (Oct 24 2019 at 21:12, on Zulip):

it gives an error on beta/nightly I think

Santiago Pastorino (Oct 24 2019 at 22:51, on Zulip):

@nikomatsakis I'm back ... this is weird

Santiago Pastorino (Oct 24 2019 at 22:51, on Zulip):
[santiago@galago niko-app (master)]$ rustup default stable
info: using existing install for 'stable-x86_64-unknown-linux-gnu'
info: default toolchain set to 'stable-x86_64-unknown-linux-gnu'

  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.38.0 (625451e37 2019-09-23)

[santiago@galago niko-app (master)]$ rustc -V
rustc 1.38.0 (625451e37 2019-09-23)
[santiago@galago niko-app (master)]$ rustup default stable
info: using existing install for 'stable-x86_64-unknown-linux-gnu'
info: default toolchain set to 'stable-x86_64-unknown-linux-gnu'

  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.38.0 (625451e37 2019-09-23)

[santiago@galago niko-app (master)]$ rustc src/main.rs
warning: function is never used: `drain_dyn`
 --> src/main.rs:3:1
  |
3 | fn drain_dyn(v: &mut Vec<Box<dyn Any>>) -> impl Iterator<Item = Box<dyn Any>> {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(dead_code)]` on by default

[santiago@galago niko-app (master)]$ rustup default nightly
info: using existing install for 'nightly-x86_64-unknown-linux-gnu'
info: default toolchain set to 'nightly-x86_64-unknown-linux-gnu'

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.40.0-nightly (0e8a4b441 2019-10-16)

[santiago@galago niko-app (master)]$ rustc -V
rustc 1.40.0-nightly (0e8a4b441 2019-10-16)
[santiago@galago niko-app (master)]$ rustup default stable
info: using existing install for 'stable-x86_64-unknown-linux-gnu'
info: default toolchain set to 'stable-x86_64-unknown-linux-gnu'

  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.38.0 (625451e37 2019-09-23)

[santiago@galago niko-app (master)]$ rustc -V
rustc 1.38.0 (625451e37 2019-09-23)
[santiago@galago niko-app (master)]$ rustc src/main.rs
warning: function is never used: `drain_dyn`
 --> src/main.rs:3:1
  |
3 | fn drain_dyn(v: &mut Vec<Box<dyn Any>>) -> impl Iterator<Item = Box<dyn Any>> {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(dead_code)]` on by default

[santiago@galago niko-app (master)]$ rustup default nightly-2019-09-23
info: using existing install for 'nightly-2019-09-23-x86_64-unknown-linux-gnu'
info: default toolchain set to 'nightly-2019-09-23-x86_64-unknown-linux-gnu'

  nightly-2019-09-23-x86_64-unknown-linux-gnu unchanged - rustc 1.39.0-nightly (1dd188489 2019-09-22)

[santiago@galago niko-app (master)]$ rustc -V
rustc 1.39.0-nightly (1dd188489 2019-09-22)
[santiago@galago niko-app (master)]$ rustc src/main.rs
error: cannot infer an appropriate lifetime
 --> src/main.rs:4:7
  |
3 | fn drain_dyn(v: &mut Vec<Box<dyn Any>>) -> impl Iterator<Item = Box<dyn Any>> {
  |                                            ---------------------------------- this return type evaluates to the `'static` lifetime...
4 |     v.drain(..)
  |     - ^^^^^
  |     |
  |     ...but this borrow...
  |
note: ...can't outlive the anonymous lifetime #1 defined on the function body at 3:1
 --> src/main.rs:3:1
  |
3 | / fn drain_dyn(v: &mut Vec<Box<dyn Any>>) -> impl Iterator<Item = Box<dyn Any>> {
4 | |     v.drain(..)
5 | | }
  | |_^
help: you can add a constraint to the return type to make it last less than `'static` and match the anonymous lifetime #1 defined on the function body at 3:1
  |
3 | fn drain_dyn(v: &mut Vec<Box<dyn Any>>) -> impl Iterator<Item = Box<dyn Any>> + '_ {
  |                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error
Santiago Pastorino (Oct 24 2019 at 22:52, on Zulip):

I guess the problem is related to something unstable that's not turned on on stable then

pnkfelix (Oct 24 2019 at 22:55, on Zulip):

@Santiago Pastorino see comments recently posted to issue, e.g. my comment

pnkfelix (Oct 24 2019 at 22:55, on Zulip):

it was a change in behavior injected since the stable

Santiago Pastorino (Oct 24 2019 at 22:56, on Zulip):

ok I wasn't aware of any issue, Niko just asked me to run cargo-bisect-rustc

pnkfelix (Oct 24 2019 at 22:56, on Zulip):

namely, #63376 landed on august 20th

pnkfelix (Oct 24 2019 at 22:56, on Zulip):

(the issue is linked in the topic)

Santiago Pastorino (Oct 24 2019 at 22:56, on Zulip):

but why does it fails on the nightly of the same date as stable

pnkfelix (Oct 24 2019 at 22:58, on Zulip):

I don't think I understand your question

pnkfelix (Oct 24 2019 at 22:59, on Zulip):

how are you mapping a given stable compiler to the corresponding nightly?

Santiago Pastorino (Oct 24 2019 at 23:57, on Zulip):

Felix, sorry, I see what’s going on

Santiago Pastorino (Oct 24 2019 at 23:57, on Zulip):

I’m with the cellphone right now

Santiago Pastorino (Oct 24 2019 at 23:58, on Zulip):

can update tomorrow

Santiago Pastorino (Oct 24 2019 at 23:58, on Zulip):

but I was having an issue with cargo-bisect-rustc I think

Santiago Pastorino (Oct 24 2019 at 23:59, on Zulip):

I believe the problem is in the exponential way of going back

Santiago Pastorino (Oct 24 2019 at 23:59, on Zulip):

I think that by coincinde just an unfortunate thing, I never hit a working version

Santiago Pastorino (Oct 24 2019 at 23:59, on Zulip):

it jumps all over the working release (I believe)

Santiago Pastorino (Oct 25 2019 at 00:00, on Zulip):

so giving the exactly right version that works is the right thing to do here

Santiago Pastorino (Oct 25 2019 at 02:37, on Zulip):

so ... to confirm here what I was saying before, sorry but I didn't pay attention to the bug

Santiago Pastorino (Oct 25 2019 at 02:37, on Zulip):

I'm just talking about the bisect run I've done

Santiago Pastorino (Oct 25 2019 at 02:38, on Zulip):

I was originally hitting a trouble that cargo-bisect-rustc going exponentially backwards just jumped over all the rights cases and tried an old rustc which failed too because of the lack of that feature probably, this is kind of a problem of the tool that I think @simulacrum is aware

Santiago Pastorino (Oct 25 2019 at 02:38, on Zulip):

after kind of manually finding one that works

Santiago Pastorino (Oct 25 2019 at 02:39, on Zulip):

I've set a start and end and run the bisect and got

Santiago Pastorino (Oct 25 2019 at 02:39, on Zulip):
[santiago@galago niko-app (master)]$ ../cargo-bisect-rustc/target/debug/cargo-bisect-rustc --start 2019-08-01 --end 2019-10-16 --preserve
checking nightly-2019-08-01
verifying the start of the range does not reproduce the regression
tested nightly-2019-08-01, got No
confirmed the start of the range does not reproduce the regression
verifying the end of the range reproduces the regression
std for x86_64-unknown-linux-gnu: 175.32 MB / 175.32 MB [===============================================================================================================================================================] 100.00 % 7.90 MB/s
tested nightly-2019-10-16, got Yes
confirmed the end of the range reproduces the regression
std for x86_64-unknown-linux-gnu: 174.98 MB / 174.98 MB [===============================================================================================================================================================] 100.00 % 7.23 MB/s
tested nightly-2019-09-08, got Yes
std for x86_64-unknown-linux-gnu: 173.91 MB / 173.91 MB [===============================================================================================================================================================] 100.00 % 7.63 MB/s
tested nightly-2019-08-20, got No
std for x86_64-unknown-linux-gnu: 174.39 MB / 174.39 MB [===============================================================================================================================================================] 100.00 % 7.39 MB/s
tested nightly-2019-08-29, got Yes
std for x86_64-unknown-linux-gnu: 173.60 MB / 173.60 MB [===============================================================================================================================================================] 100.00 % 7.66 MB/s
tested nightly-2019-08-24, got Yes
std for x86_64-unknown-linux-gnu: 173.78 MB / 173.78 MB [===============================================================================================================================================================] 100.00 % 7.80 MB/s
tested nightly-2019-08-22, got Yes
std for x86_64-unknown-linux-gnu: 173.65 MB / 173.65 MB [===============================================================================================================================================================] 100.00 % 7.65 MB/s
tested nightly-2019-08-21, got Yes
searched toolchains nightly-2019-08-01 through nightly-2019-10-16
regression in nightly-2019-08-21
simulacrum (Oct 25 2019 at 02:40, on Zulip):

Yes, there is no (known to me at least) algorithm that is better than linear search if your "function" that you're trying to bisect isn't monotonic.

Santiago Pastorino (Oct 25 2019 at 02:40, on Zulip):

yep

Santiago Pastorino (Oct 25 2019 at 02:40, on Zulip):

maybe a good thing to "detect" this problem is seeing if the failure is different?

Santiago Pastorino (Oct 25 2019 at 02:41, on Zulip):

but that's not good neither a small change in diagnostics would make things different

Santiago Pastorino (Oct 25 2019 at 02:41, on Zulip):

maybe looking for huger differences or an error code or something

Santiago Pastorino (Oct 25 2019 at 02:42, on Zulip):

@nikomatsakis so regression in nightly 2019-08-21, sorry but I didn't investigate on the issue, by know you may already be aware on what's going on and where the problem is but if you need I could also bisect from 2019-08-20 to 2019-08-21 looking for the commit that originates the problem

lqd (Oct 25 2019 at 09:28, on Zulip):

you probably won't need to do that, it is very likely #63376 as Felix mentioned; I just ran cargo-bisect-rustc to get you the commit (and it worked fine, there's no problem of exponentially going back in this case) and it's #63715 the rollup which merged this PR

lqd (Oct 25 2019 at 09:31, on Zulip):

(which reminds me both 1) that I've forgotten I wanted to document how to get bors' commits in the cargo-bisect-rustc tutorial 2) that the tool might need something to help continue bisection with the more frequent rollups)

simulacrum (Oct 25 2019 at 11:52, on Zulip):

yeah I've tried "manual bisection" in the past -- getting the nouns right is usually hard

simulacrum (Oct 25 2019 at 11:52, on Zulip):

e.g. do you ask "is this still the regression?" or "was this commit fixing it?" or what

Santiago Pastorino (Oct 25 2019 at 13:49, on Zulip):

you probably won't need to do that, it is very likely #63376 as Felix mentioned; I just ran cargo-bisect-rustc to get you the commit (and it worked fine, there's no problem of exponentially going back in this case) and it's #63715 the rollup which merged this PR

yeah, sorry for generating confusion here, I wasn't working on the issue, just Niko asked me to run cargo-bisect-rustc because I was coincidentially working on the tool

Santiago Pastorino (Oct 25 2019 at 13:49, on Zulip):

the tool if you don't give any parameters indeed doesn't report anything because it jumps over all the working versions, just try cargo-bisect-rustc without any param

Last update: Nov 22 2019 at 04:30UTC