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

Destructuring struct with dtor by-ref #6344

Closed
huonw opened this issue May 8, 2013 · 4 comments
Closed

Destructuring struct with dtor by-ref #6344

huonw opened this issue May 8, 2013 · 4 comments

Comments

@huonw
Copy link
Member

huonw commented May 8, 2013

struct A { x: uint }

impl Drop for A {
    fn finalize(&self) {}
}

fn main() {
    let a = A { x: 0 };

    let x = &a.x;

    match a {
        A { x : ref x } => {}
    }
}
dtor-struct.rs:13:8: 13:26 error: deconstructing struct not allowed in pattern (it has a destructor)
dtor-struct.rs:13         A { x : ref x } => {}
                          ^~~~~~~~~~~~~~~~~~
error: aborting due to previous error

The let and match seem to be morally identical, but one is invalid. (Making the match form valid makes syntax extensions/macros easier.)

(Caused #6341.)

@nikomatsakis
Copy link
Contributor

should be ok so long as there are no by move bindings.

bors added a commit that referenced this issue May 11, 2013
**Caveat**: With the current commit, this check only works for `match`s, the checks (incorrectly) do not run for patterns in `let`s, and invalid/unsafe code compiles.

I don't know how to fix this, I experimented with some things to try to make let patterns and match patterns run on the same code (since this would presumably fix many of the other unsoundness issues of let-patterns, e.g. #6225), but I don't understand enough of the code. (I think I heard someone talking about a fix for `let` being in progress?)

Fixes #6344 and #6341.
@emberian
Copy link
Member

See #3874

@huonw
Copy link
Member Author

huonw commented Jun 22, 2013

(@cmr this is closed and fixed.)

@emberian
Copy link
Member

There's a testcase referencing this issue that's xfailed and broken though

flip1995 pushed a commit to flip1995/rust that referenced this issue Jan 2, 2021
…=flip1995

Reassign default private

changelog: fix field_reassign_with_default false positive

* Fix rust-lang#6344
* Fix assumption that `field: Default::default()` is the same as `..Default::default()`
* Cleanup some redundant logic
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants