Skip to content

Conversation

@huonw
Copy link
Contributor

@huonw huonw commented 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.

@rust-highfive
Copy link
Contributor

r? @nick29581

(rust_highfive has picked a reviewer for you, use r? to override)

@huonw
Copy link
Contributor Author

huonw commented Jan 6, 2015

r? @nikomatsakis

@rust-highfive rust-highfive assigned nikomatsakis and unassigned nrc Jan 6, 2015
@nikomatsakis
Copy link
Contributor

@huonw it occurs to me that this check might not quite work for generic structs -- but there is some question as to the correct behavior of Drop in the case of generic structs anyhow (i.e., if you have struct Foo(T), is it ok to impl<T:Bar> Drop for Foo?). Right now it's a moot point because #[unsafe_dtor] is required for generic structs anyway, but eventually that will not be true.

(promoting to a comment on the PR so it doesn't go away after rebasing etc)

@nikomatsakis
Copy link
Contributor

So I think we want to be careful about generic structs, but that's probably a separate PR. Hence r+.

bors added a commit that referenced this pull request 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 huonw force-pushed the no-drop-and-copy branch from 8ba4cfc to 0ea534f Compare January 6, 2015 23:08
bors added a commit that referenced this pull request 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.
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.
@huonw huonw force-pushed the no-drop-and-copy branch from 0ea534f to 3c1ca17 Compare January 7, 2015 23:07
bors added a commit that referenced this pull request 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.
alexcrichton added a commit to alexcrichton/rust that referenced this pull request Jan 8, 2015
@bors bors merged commit 3c1ca17 into rust-lang:master Jan 8, 2015
lnicola pushed a commit to lnicola/rust that referenced this pull request Sep 18, 2025
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

Successfully merging this pull request may close these issues.

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

5 participants