Skip to content
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-lexical lifetimes has different behavior for Vec<&i32> and Vec<&String> #46953

Closed
shepmaster opened this issue Dec 22, 2017 · 4 comments
Closed
Labels
A-NLL Area: Non-lexical lifetimes (NLL) C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@shepmaster
Copy link
Member

With 1.24.0-nightly (2017-12-21 250b492):

This compiles:

#![feature(nll)]

fn main() {
    let mut vec = Vec::new();

    let a = 1;
    vec.push(&a);

    let b = 2;
    vec.push(&b);

    println!("{:?}", vec);
}

But this does not:

#![feature(nll)]

fn f() {
    let mut vec = Vec::new();

    let a = String::from("");
    vec.push(&a);

    let b = String::from("");
    vec.push(&b);

    println!("{:?}", vec);
}

fn main() {}
error[E0597]: `a` does not live long enough
  --> src/main.rs:7:14
   |
7  |     vec.push(&a);
   |              ^^ borrowed value does not live long enough
...
13 | }
   |  - borrowed value only lives until here
   |
   = note: borrowed value must be valid for lifetime '_#11r...

/cc @arielb1 @nikomatsakis

@shepmaster shepmaster added A-NLL Area: Non-lexical lifetimes (NLL) C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-compiler-nll labels Dec 22, 2017
@Ryman
Copy link
Contributor

Ryman commented Dec 23, 2017

The first example has constant propagation (or whatever that's called these days) occurring, you can add let _: Vec<&'static i32> = vec; to the end and it still compiles which shows they're getting promoted to statics.

In the second, if you bring a and b to be above vec then the example works. Isn't this necessary due to destructor ordering? I'm not up to date on NLL enough to know if that's intended to work.

@CryZe
Copy link
Contributor

CryZe commented Dec 23, 2017

This might be a duplicate of #46935 where I also noticed that drop and non-drop types behave very differently.

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Dec 23, 2017 via email

@nikomatsakis
Copy link
Contributor

Both versions compile now: https://play.rust-lang.org/?gist=79c56c0a2310df3880212d7124be65cd&version=nightly

Fixed by #46984

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-NLL Area: Non-lexical lifetimes (NLL) C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants