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

Require that types cannot implement both Drop and Copy. #20631

Merged
merged 1 commit into from
Jan 8, 2015

Conversation

huonw
Copy link
Member

@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
Collaborator

r? @nick29581

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

@huonw
Copy link
Member 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
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