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

Comments

Projects
None yet
5 participants
@Aatch
Contributor

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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

Require that types cannot implement both Drop and Copy.
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

auto merge of #20631 : huonw/rust/no-drop-and-copy, r=nikomatsakis
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

Require that types cannot implement both Drop and Copy.
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

auto merge of #20631 : huonw/rust/no-drop-and-copy, r=nikomatsakis
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

auto merge of #20631 : huonw/rust/no-drop-and-copy, r=nikomatsakis
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

Require that types cannot implement both Drop and Copy.
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

auto merge of #20631 : huonw/rust/no-drop-and-copy, r=nikomatsakis
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

@kennytm kennytm referenced this issue Feb 14, 2017

Closed

Unions 1.2 #1897

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment