Bug: `borrowed value is only valid for unknown scope: 31`

[honzasp]

Hi,

while struggling with Rust pointers, I got a message from the compiler asking for a bug report. I reduced the file to:

struct HasString<'self> {
  the_string: &'self str,
}

impl<'self> HasString<'self> {
  fn new(that_string: ~str) -> ~HasString {
    ~HasString { the_string: that_string }
  }
}

The message says:

$ rustc --test bug.rs
bug.rs:7:29: 7:40 error: illegal borrow: borrowed value does not live long enough
bug.rs:7     ~HasString { the_string: that_string }
                                      ^~~~~~~~~~~
bug.rs:6:42: 8:3 note: borrowed pointer must be valid for the anonymous lifetime #2 defined on the block at 6:42...
bug.rs:6   fn new(that_string: ~str) -> ~HasString {
bug.rs:7     ~HasString { the_string: that_string }
bug.rs:8   }
note: ...but borrowed value is only valid for unknown scope: 31.  Please report a bug.
error: aborting due to previous error

Version is:

$ rustc --version
rustc 0.6
host: i686-unknown-linux-gnu

If the function is out of the impl, like this:

struct HasString<'self> {
  the_string: &'self str,
}

fn new(that_string: ~str) -> ~HasString {
  ~HasString { the_string: that_string }
}

The message says nothing about bugs:

$ rustc --test no_bug.rs 
no_bug.rs:6:27: 6:38 error: illegal borrow: borrowed value does not live long enough
no_bug.rs:6   ~HasString { the_string: that_string }
                                       ^~~~~~~~~~~
no_bug.rs:5:40: 7:1 note: borrowed pointer must be valid for the anonymous lifetime #2 defined on the block at 5:40...
no_bug.rs:5 fn new(that_string: ~str) -> ~HasString {
no_bug.rs:6   ~HasString { the_string: that_string }
no_bug.rs:7 }
no_bug.rs:5:0: 7:1 note: ...but borrowed value is only valid for the function body at 5:0
no_bug.rs:5 fn new(that_string: ~str) -> ~HasString {
no_bug.rs:6   ~HasString { the_string: that_string }
no_bug.rs:7 }
error: aborting due to previous error

Jan Špaček

[thestinger]

The error message is still buggy in incoming, but the compiler is correct in not compiling it. The string will be gone at the end of the function call and the slice has to be outlived by it.

[Aatch]

The error message no longer suggests it's a bug.