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

Opt-in copy causes types that shouldn't be Copy to be copy #20126

Closed
Aatch opened this issue Dec 22, 2014 · 5 comments
Closed

Opt-in copy causes types that shouldn't be Copy to be copy #20126

Aatch opened this issue Dec 22, 2014 · 5 comments
Assignees
Labels

Comments

@Aatch
Copy link
Contributor

@Aatch Aatch commented Dec 22, 2014

Basically, it's now possible to write:

struct Foo { a: int };

impl Drop for Foo { fn drop(&mut self) { } }

impl Copy for Foo { }

and have everything work. This unfortunately means that doing something like let a = b with a Foo will zero b, but not move it.

/cc @nikomatsakis @pcwalton

@nikomatsakis
Copy link
Contributor

@nikomatsakis nikomatsakis commented Dec 23, 2014

I noticed this possibility too and was debating if this is a problem. It's not clear to me. Probably best to disallow it for now.

@Aatch
Copy link
Contributor Author

@Aatch Aatch commented Dec 23, 2014

@nikomatsakis at the very least, it's causing incorrect behaviour at runtime, since it's zeroing out types like a move, but not forbidding the use of them like a copy.

@ben0x539
Copy link
Contributor

@ben0x539 ben0x539 commented Dec 25, 2014

Looks unsafe to me:

struct Foo { a: &'static int }
impl Drop for Foo { fn drop(&mut self) { } }
impl Copy for Foo { }

fn main() {
    static I: int = 42;
    let x = Foo { a: &I };
    let y = x;
    println!("{}\n{}", y.a, x.a);
}

Program received signal SIGSEGV, Segmentation fault.
0x0000555555598e5c in fmt::num::i64.fmt..Show::fmt::he672872527c9858bIvv ()

@nikomatsakis
Copy link
Contributor

@nikomatsakis nikomatsakis commented Jan 3, 2015

I agree that combining it with zeroing is unsafe. If zeroing did not occur, or we did not zero for types that were copy, there wouldn't necessarily be a problem.

@nikomatsakis
Copy link
Contributor

@nikomatsakis nikomatsakis commented Jan 3, 2015

Anyhow, it's easiest to forbid it for now. We can always make it legal later if someone comes up with a persuasive use case. Idempotent destructors seem like a bit of an odd thing.

@huonw huonw self-assigned this Jan 6, 2015
huonw added a commit to huonw/rust that referenced this issue Jan 6, 2015
Opt-in built-in traits allowed one to explicitly implement both `Drop`
and `Copy` for a type. This can theoretically make some sense, but the
current implementation means it is codegened totally incorrectly which
can lead to memory unsafety, so this feature is disabled for now.

Fixes rust-lang#20126.
bors added a commit that referenced this issue Jan 6, 2015
Opt-in built-in traits allowed one to explicitly implement both `Drop`
and `Copy` for a type. This can theoretically make some sense, but the
current implementation means it is codegened totally incorrectly which
can lead to memory unsafety, so this feature is disabled for now.

Fixes #20126.
huonw added a commit to huonw/rust that referenced this issue Jan 6, 2015
Opt-in built-in traits allowed one to explicitly implement both `Drop`
and `Copy` for a type. This can theoretically make some sense, but the
current implementation means it is codegened totally incorrectly which
can lead to memory unsafety, so this feature is disabled for now.

Fixes rust-lang#20126.
bors added a commit that referenced this issue Jan 7, 2015
Opt-in built-in traits allowed one to explicitly implement both `Drop`
and `Copy` for a type. This can theoretically make some sense, but the
current implementation means it is codegened totally incorrectly which
can lead to memory unsafety, so this feature is disabled for now.

Fixes #20126.
bors added a commit that referenced this issue Jan 7, 2015
Opt-in built-in traits allowed one to explicitly implement both `Drop`
and `Copy` for a type. This can theoretically make some sense, but the
current implementation means it is codegened totally incorrectly which
can lead to memory unsafety, so this feature is disabled for now.

Fixes #20126.
huonw added a commit to huonw/rust that referenced this issue Jan 7, 2015
Opt-in built-in traits allowed one to explicitly implement both `Drop`
and `Copy` for a type. This can theoretically make some sense, but the
current implementation means it is codegened totally incorrectly which
can lead to memory unsafety, so this feature is disabled for now.

Fixes rust-lang#20126.
bors added a commit that referenced this issue Jan 8, 2015
Opt-in built-in traits allowed one to explicitly implement both `Drop`
and `Copy` for a type. This can theoretically make some sense, but the
current implementation means it is codegened totally incorrectly which
can lead to memory unsafety, so this feature is disabled for now.

Fixes #20126.
@bors bors closed this in #20631 Jan 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

5 participants