lifetime

Expanding Rust Lifetime

做~自己de王妃 提交于 2019-12-05 01:06:05
I have a bit of code that I'm fighting with. It's a little helper function that should return a Vec<&str> to the calling function. I can't seem to get the lifetime right, though. Here is the code snippet: fn take_symbol<'a>(ch: &'a str, current: &'a mut String) -> &'a mut TokenList<'a> { let out = TokenList::<'a>::new(); out.push(current.as_str()); out.push(ch); *current = String::new(); &mut out } The compiler is telling me: error: 'out' does not live long enough and that the reference must be valid for the lifetime of 'a , but it looks to me like it is defined for 'a . I have also tried

Borrowed value does not live long enough when creating a Vec

*爱你&永不变心* 提交于 2019-12-04 11:28:22
Editor's note: This question was asked before Rust 1.0. Since then, many functions and types have changed, as have certain language semantics. The code in the question is no longer valid, but the ideas expressed in the answers may be. I'm trying to list the files in a directory and copy the filename to my own Vec . I've tried several solutions, but it always ends up with a problem of not being able to create long enough living variables. I don't understand my mistake. fn getList(action_dir_path : &str) -> Vec<&str> { let v = fs::readdir(&Path::new(action_dir_path)) .unwrap() .iter() .map(|&x|

How do I return a boxed closure from a method that has a reference to the struct?

Deadly 提交于 2019-12-04 10:44:07
I have a structure that contains a value and I want to obtain a function that operates on this value: struct Returner { val: i32, } impl<'a> Returner { fn get(&'a self) -> Box<Fn(i32) -> i32> { Box::new(|x| x + self.val) } } This fails compilation: error[E0495]: cannot infer an appropriate lifetime due to conflicting requirements --> src/main.rs:7:18 | 7 | Box::new(|x| x + self.val) | ^^^^^^^^^^^^^^^^ | note: first, the lifetime cannot outlive the lifetime 'a as defined on the impl at 5:1... --> src/main.rs:5:1 | 5 | impl<'a> Returner { | ^^^^^^^^^^^^^^^^^ = note: ...so that the types are

How to Leverage browser caching at ASP.net IIS 7.5

可紊 提交于 2019-12-04 08:34:05
问题 The following cacheable resources have a short freshness lifetime. Specify an expiry of at least one week in the future for the following resources: http://pagespeed.googlelabs.com suggest me this for my website as a high priority. I am using windows server 2008 r2 netframework 4.0 asp.net IIS 7.5 . How do i do this ? This is the direct url for you to see : http://pagespeed.googlelabs.com/#url=www.monstermmorpg.com&mobile=false&rule=LeverageBrowserCaching 回答1: You might start here with this

Cannot infer an appropriate lifetime when storing Peekable iterators in a vector

徘徊边缘 提交于 2019-12-04 06:23:49
问题 The following code works perfectly: use std::iter::Peekable; use std::slice::Iter; fn has_next(iter: &mut Peekable<Iter<usize>>) -> bool { match iter.peek() { Some(_) => true, None => false, } } fn print_iters(iters: &mut Vec<Peekable<Iter<usize>>>) { for iter in iters.iter_mut() { if has_next(iter) { match iter.next() { Some(x) => println!("{}", x), None => {} } } } } fn main() { let v1 = vec![2, 4, 6, 8]; let v2 = vec![1, 3, 5, 7]; let mut iters = Vec::new(); iters.push((v1.iter().peekable(

How to assign to the variable used in match expression inside a match branch?

南笙酒味 提交于 2019-12-04 05:29:09
问题 I'm trying to implement a general function join() that can work on any iterator of iterators. I have a problem with the borrow checker in a match expression inside the next() method implementation. Here is a simplified version of my code: pub struct Join<I> where I: Iterator, I::Item: IntoIterator, { outer_iter: I, inner_iter: Option<<I::Item as IntoIterator>::IntoIter>, } impl<I> Join<I> where I: Iterator, I::Item: IntoIterator, { pub fn new(mut iter: I) -> Join<I> { let inner_iter = iter

Value doesn't live long enough when put in struct

五迷三道 提交于 2019-12-04 05:05:41
问题 I'm trying to work with LLVM in Rust using this crate. I'm trying to create a code generator struct to hold the context, module, and builder for me, but when I try to compile I get an error message that says c does not live long enough . How can I get this to compile, and why isn't c living long enough? Code: use llvm::*; use llvm::Attribute::*; pub struct CodeGen<'l> { context: CBox<Context>, builder: CSemiBox<'l, Builder>, module: CSemiBox<'l, Module>, } impl<'l> CodeGen<'l> { pub fn new()

How to specify a lifetime for an Option<closure>?

折月煮酒 提交于 2019-12-04 04:58:40
I'm trying to put a field on a struct that should hold an Option<closure> . However, Rust is yelling at me that I have to specify the lifetime (not that I would have really grokked that yet). I'm trying my best to do so but Rust is never happy with what I come up with. Take a look at my inline comments for the compile errors I got. struct Floor{ handler: Option<|| ->&str> //this gives: missing lifetime specifier //handler: Option<||: 'a> // this gives: use of undeclared lifetime name `'a` } impl Floor { // I guess I need to specify life time here as well // but I can't figure out for the life

Why do I get a lifetime error when I use a mutable reference in a struct instead of an immutable reference?

99封情书 提交于 2019-12-04 04:53:55
问题 This code works fine (Playground): struct F<'a> { x: &'a i32, } impl<'a> F<'a> { fn get<'b>(&'b self) -> &'a i32 { self.x } } fn main() { let x = 3; let y = F { x: &x }; let z = y.get(); } But when I change x to be a mutable reference instead (Playground): struct Foo<'a> { x: &'a mut i32, // <-- `mut` added } impl<'a> Foo<'a> { fn get(&self) -> &'a i32 { self.x } } fn main() { let mut x = 3; // <-- `mut` added let y = Foo { x: &mut x }; // <-- `mut` added let z = y.get(); } I get this error:

In Rust, how do you explicitly tie the lifetimes of two objects together, without referencing eachother?

跟風遠走 提交于 2019-12-04 04:18:09
问题 The specific case where I ran into this was in using OpenGL, writing struct s for a VertexBuffer and VertexArray . Each struct is, in essence, a single GLuint that refers to the OpenGL object. In the simplest case, a VertexArray has exactly one VertexBuffer associated with it. The problem is that the VertexArray cannot live longer than its associated VertexBuffer . Rust doesn't know this though, since the reference that the VertexArray holds is internal to OpenGL, so it will have no problem