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

Static lifetimes checking regression in rustc 1.41.0 #69114

Closed
ilyavennik opened this issue Feb 12, 2020 · 4 comments · Fixed by #69145
Closed

Static lifetimes checking regression in rustc 1.41.0 #69114

ilyavennik opened this issue Feb 12, 2020 · 4 comments · Fixed by #69145
Assignees
Labels
A-borrow-checker Area: The borrow checker A-lifetimes Area: Lifetimes / regions C-bug Category: This is a bug. I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@ilyavennik
Copy link

ilyavennik commented Feb 12, 2020

I tried this code:

static FOO: u8 = 42;
static mut BAR: &'static u8 = &FOO;

fn main() {
    unsafe {
        println!("{}", BAR);
        foo();
        println!("{}", BAR);
    }
}

fn foo() {
    let n = 42;
    unsafe {
        BAR = &n;
    }
}

I expected to see this:

error[E0597]: `n` does not live long enough
  --> src/main.rs:15:15
   |
15 |         BAR = &n;
   |         ------^^
   |         |     |
   |         |     borrowed value does not live long enough
   |         assignment requires that `n` is borrowed for `'static`
16 |     }
17 | }
   | - `n` dropped here while still borrowed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0597`.

Instead, happens undefined behavior. Program successfully compiles in the Rust stable 1.41.0 but fails to compile in stable 1.40.0 (thats what I want).

@ilyavennik ilyavennik added the C-bug Category: This is a bug. label Feb 12, 2020
@jonas-schievink jonas-schievink added A-borrow-checker Area: The borrow checker A-lifetimes Area: Lifetimes / regions I-nominated I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 12, 2020
@ecstatic-morse
Copy link
Contributor

Regressed in a449535, likely #66587 cc @matthewjasper.

@Centril Centril added the P-high High priority label Feb 13, 2020
@nikomatsakis
Copy link
Contributor

Visited in the compiler team triage meeting. It would be good to look into closing this ASAP. @matthewjasper do you think you'll have time to investigate? If not, I'd want to find someone else.

@nikomatsakis
Copy link
Contributor

We've assigned this speculatively to @matthewjasper -- if you think you won't be able to investigate promptly, though, feel free to unassign and ping t-compiler for reassignment, @matthewjasper.

@eddyb
Copy link
Member

eddyb commented Feb 13, 2020

I expected the behavior to match that of this example (which still errors):

fn foo(p: *mut &'static u8) {
    let n = 42;
    unsafe {
        *p = &n;
    }
}

I wonder if the 'static gets erased somehow. Maybe an "user type annotation" is required on the *mut T from a static mut FOO: T, to give it a lifetime'd type?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-borrow-checker Area: The borrow checker A-lifetimes Area: Lifetimes / regions C-bug Category: This is a bug. I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants