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

"borrow of possibly uninitialized variable" instead of "use of moved value" #52669

Closed
stephaneyfx opened this issue Jul 24, 2018 · 6 comments
Closed
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-NLL Area: Non-lexical lifetimes (NLL) C-enhancement Category: An issue proposing an enhancement or a PR with one. NLL-diagnostics Working towards the "diagnostic parity" goal

Comments

@stephaneyfx
Copy link
Contributor

stephaneyfx commented Jul 24, 2018

NLL combined with a struct field assignment gives an error mentioning the use/borrow of an uninitialized variable instead of the use/borrow of a moved variable.

Reproduction example

Simplified code based on @Yatekii's question on IRC
Playground

#![feature(nll)]

struct A {
    b: B,
}

#[derive(Clone)]
struct B;

fn foo(_: A) {}

fn bar(mut a: A) -> B {
    // Commenting the line below gives a move error instead of uninitialized
    // error.
    a.b = B;
    foo(a);
    a.b.clone()
}

fn main() {}

Expected behavior

The compiler gives an error about using a moved value, similar to the following:

Without NLL:

error[E0382]: use of moved value: `a.b`
  --> src/main.rs:17:5
   |
16 |     foo(a);
   |         - value moved here
17 |     a.b.clone()
   |     ^^^ value used here after move
   |
   = note: move occurs because `a` has type `A`, which does not implement the `Copy` trait

With NLL but without the field assignment:

error[E0382]: borrow of moved value: `a.b`
  --> src/main.rs:17:5
   |
16 |     foo(a);
   |         - value moved here
17 |     a.b.clone()
   |     ^^^ value borrowed here after move
   |
   = note: move occurs because `a` has type `A`, which does not implement the `Copy` trait

Actual behavior

The error mentions an uninitialized value instead of a moved value:

error[E0381]: borrow of possibly uninitialized variable: `a.b`
  --> src/main.rs:17:5
   |
17 |     a.b.clone()
   |     ^^^ use of possibly uninitialized `a.b`
@kennytm kennytm added C-enhancement Category: An issue proposing an enhancement or a PR with one. A-diagnostics Area: Messages for errors, warnings, and lints A-NLL Area: Non-lexical lifetimes (NLL) WG-compiler-nll NLL-diagnostics Working towards the "diagnostic parity" goal labels Jul 24, 2018
@nikomatsakis nikomatsakis added this to the Rust 2018 RC milestone Aug 21, 2018
@nikomatsakis
Copy link
Contributor

I would classify this as a "minor diagnostic improvement". I'm moving to the Milestone and marking as E-needs-mentor.

@csmoe
Copy link
Member

csmoe commented Aug 22, 2018

EDIT: Duplicate of #21232


this issue may caused by Place checking I guess:

// 2. Move of `a.b.c`, use of `a.b.c.d` (without first reinitializing `a.b.c.d`)

// 7. Move of `a.b.c` then reinit of `a.b.c.d`, use of `a.b.c.d`

the comments reason why the uninitialized lint emitted here: for place a.b, if a is moved, then the usage of projection a.b will be treated as uninitialized, let's take an experiment:
https://play.rust-lang.org/?gist=12d7880fc733e74b5bac20119465ada3&version=nightly&mode=debug&edition=2015

fn bar(mut a: A) -> B {
    a.b = B;
    foo(a);
    a.b
}

=>

error[E0381]: use of possibly uninitialized variable: `a.b`
  --> src/main.rs:16:5
   |
16 |     a.b
   |     ^^^ use of possibly uninitialized `a.b`

==========

instead of using place a.b, we return a:

```rust
fn too(mut a: A) -> A {
    a.b = B;
    foo(a);
    a
}

=>

error[E0382]: use of moved value: `a`
  --> src/main.rs:16:5
   |
15 |     foo(a);
   |         - value moved here
16 |     a
   |     ^ value used here after move
   |
   = note: move occurs because `a` has type `A`, which does not implement the `Copy` trait

@nikomatsakis
Copy link
Contributor

Clearly not an RC blocker

@nikomatsakis
Copy link
Contributor

Still occurs

@nikomatsakis
Copy link
Contributor

Seems worth fixing to me for RC2 — this could be a "new user stumbling point".

@nikomatsakis
Copy link
Contributor

Might be a good fit for @spastorino, who recently did #46590, which is touching the same code that produces this error. Thoughts @spastorino ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-NLL Area: Non-lexical lifetimes (NLL) C-enhancement Category: An issue proposing an enhancement or a PR with one. NLL-diagnostics Working towards the "diagnostic parity" goal
Projects
None yet
Development

No branches or pull requests

5 participants