These are chat archives for rust-lang/rust

19th
Sep 2017
Michal 'vorner' Vaner
@vorner
Sep 19 2017 08:12

Hello. I've a problem with lifetimes I don't know how to solve in an elegant way. Let's say I have a trait:

trait Queryable {
  fn query(&self, q: &Query) -> Box<Iterator<Item = Result>>;
}

Now, I want to implement it for some type. But the iterator I return would like to be bounded by the &self's lifetime. However, as it's inside that Box, it insists on being 'static.

I know the usual way to solve this is to introduce an associated type into the trait. But I need the trait to be object safe. Is there a way to have it object safe and hold the reference (and still be an iterator ‒ I probably could create some iteratol-like trait that is lifetime-parametric)?

Or is the only (reasonable) way to just return Vec<Result>?
Denis Lisov
@tanriol
Sep 19 2017 08:55
@vorner Something like the following?
trait Queryable<'a> {
  fn query(&'a self, q: &Query) -> Box<Iterator<Item = Result<&'a str, ()>>>;
}
Michal 'vorner' Vaner
@vorner
Sep 19 2017 08:56
@tanriol I don't think so, no. The Result (sorry for confusing it with the library type) is an owned type. The iterator itself isn't.
I want to do something like Box::new(self.internal_vec().iter().filter(…))
but then the iterator contains reference to self.
Denis Lisov
@tanriol
Sep 19 2017 09:06
Ok, then how about
trait Queryable<'a> {
  fn query(&'a self, q: &Query) -> Box<Iterator<Item = QueryResult> + 'a>;
}
Michal 'vorner' Vaner
@vorner
Sep 19 2017 09:07
That might work, I'll try
Michal 'vorner' Vaner
@vorner
Sep 19 2017 09:20
@tanriol Thanks, it led to a working solution (I had even a little bit more complex use case, but made it work in the end).
Roman Proskuryakov
@kpp
Sep 19 2017 11:58
is there any way to switch cargo version using rustup?
Denis Lisov
@tanriol
Sep 19 2017 11:59
Do you want to have rustc and cargo from different toolchains?
Roman Proskuryakov
@kpp
Sep 19 2017 12:00
no
I want to build an old example from 2015 using rust 1.5.0
Ah, I see
Denis Lisov
@tanriol
Sep 19 2017 12:02
If you install the 1.5.0 toolchain, it should be using the corresponding cargo version.
Roman Proskuryakov
@kpp
Sep 19 2017 12:02
$ cargo --version
cargo 0.6.0-nightly (e1ed995 2015-10-22)
$ cargo build --verbose
Failed to parse registry's information for: serde

Caused by:
  the given version requirement is invalid
Michal 'vorner' Vaner
@vorner
Sep 19 2017 12:12
If a test might break by getting stuck (I'm playing with futures and channels), what do you use to make sure it fails and doesn't run forever (eg. in a CI service)?
I've seen the timebomb crate, but I can't say I really like it that much.
Roman Proskuryakov
@kpp
Sep 19 2017 12:34
travis kills your cargo test if it is not responding for N minutes
Michal 'vorner' Vaner
@vorner
Sep 19 2017 13:01
This is a work project and my company doesn't use travis. I'm afraid there's no limit (or it at last isn't reasonable) in our gitlab CI setup.
Alex Burka
@durka
Sep 19 2017 15:03
what's wrong with dead simple thread::spawn(|| { thread::sleep(LIMIT); eprintln!("too slow!"); process::exit(); });
Michal 'vorner' Vaner
@vorner
Sep 19 2017 15:05
@durka That is global for the process, not for the single test. It can fire just because I have too many tests, not because one of them was slow. And it doesn't give me the name of the test that was slow. But if there's nothing better, I might probably use that.
Alex Burka
@durka
Sep 19 2017 15:07
yeah true
could be customized to do that in each test, by checking an atomic to see whether the test actually finished
I dunno what's bad about the timebomb crate specifically, though it looks dead :/ (github repo no longer exists)
Michal 'vorner' Vaner
@vorner
Sep 19 2017 15:09
Yes, looking dead is one problem. The other is, you need to wrap the whole test into a closure, which is a bit uncomfortable. I only wanted to ask if someone knew (or used) something better.
Cory Duplantis
@ctfhacker
Sep 19 2017 16:04
Anyone here leveraging DynamoRIO by chance with Rust?
Roman Proskuryakov
@kpp
Sep 19 2017 16:11
can anyone help me to compile hyper 0.7 using rust 1.5.0?
Failed to parse registry's information for: serde
DEBUG:cargo::core::registry: load/match    registry https://github.com/rust-lang/crates.io-index
DEBUG:cargo::core::resolver: checking if libc v0.2.30 is already activated
DEBUG:cargo::core::resolver: checking if winapi v0.2.8 is already activated
DEBUG:cargo::core::resolver: checking if kernel32-sys v0.2.2 is already activated
DEBUG:cargo::core::registry: load/match    registry https://github.com/rust-lang/crates.io-index
DEBUG:cargo: handle_error; err=CliError { error: ChainedError { error: Failed to parse registry's information for: serde, cause: InvalidVersionRequirement }, unknown: true, exit_code: 101 }
Failed to parse registry's information for: serde
Roman Proskuryakov
@kpp
Sep 19 2017 16:19
If I install rustup default 1.5.0 and run custom cargo from .rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo, will it use rustc 1.5.0?
Steve Klabnik
@steveklabnik
Sep 19 2017 16:20
probably; the right way is to use the RUSTC env var to point at the rustc you want
@ctfhacker i have never heard of that
David Tolnay
@dtolnay
Sep 19 2017 16:20
@kpp you are going to need at least Rust 1.12 to build Serde 1.0 or Serde 0.9, and at least Rust 1.8.0 to build Serde 0.8
Steve Klabnik
@steveklabnik
Sep 19 2017 16:21
... but yeah also what @dtolnay said
Cory Duplantis
@ctfhacker
Sep 19 2017 16:21
@steveklabnik It's a dynamic binary instrumentation framework
Roman Proskuryakov
@kpp
Sep 19 2017 16:21
no no, I am compiling serde v0.6.6
David Tolnay
@dtolnay
Sep 19 2017 16:21
still requires Rust 1.8.0 i think
Steve Klabnik
@steveklabnik
Sep 19 2017 16:21
@ctfhacker neat!
David Tolnay
@dtolnay
Sep 19 2017 16:22
iirc there was a breaking change in how crates.io handles pre-release versions
Roman Proskuryakov
@kpp
Sep 19 2017 16:22
yes
@dhtolnay that's why I want to use a newest version of cargo with an old rustc
with RUSTC= i get:
.rustup/toolchains/1.5.0-x86_64-unknown-linux-gnu/bin/rustc: error while loading shared libraries: librustc_driver-35c36e89.so: cannot open shared object file: No such file or directory
Roman Proskuryakov
@kpp
Sep 19 2017 16:34
Nice
$ .rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo rustc -- --version
rustc 1.5.0 (3d7cd77e4 2015-12-04)
thank you
David Tolnay
@dtolnay
Sep 19 2017 16:37
i got cargo nightly + rust 1.5 working with this:
LD_LIBRARY_PATH=~/.rustup/toolchains/1.5.0-x86_64-unknown-linux-gnu/lib RUSTC=~/.rustup/toolchains/1.5.0-x86_64-unknown-linux-gnu/bin/rustc cargo build
next step is finding a way to pin the version of num / num-traits because they no longer support 1.5.0
cargo update -p num --precise 0.1.29
David Tolnay
@dtolnay
Sep 19 2017 16:42
@kpp now it successfully compiles a dependency on serde 0.6 for me
Roman Proskuryakov
@kpp
Sep 19 2017 16:43
thank you