Generate builtin impls for `Clone` #43690

scalexm · 2017-08-05T17:48:06Z

This fixes a long-standing ICE and limitation where some builtin types implement Copy but not Clone (whereas Clone is a super trait of Copy).

However, this PR has a few side-effects:

Clone is now marked as a lang item.
[T; N] is now Clone if T: Clone (currently, only if T: Copy and for N <= 32).
fn foo<'a>() where &'a mut (): Clone { } won't compile anymore because of how bounds for builtin traits are handled (e.g. same thing currently if you replace Clone by Copy in this example). Of course this function is unusable anyway, an error would pop as soon as it is called.

Hence, I'm wondering wether this PR would need an RFC...
Also, cc-ing @nikomatsakis, @arielb1.

Related issues: #28229, #24000.

rust-highfive · 2017-08-05T17:48:11Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @eddyb (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

eddyb · 2017-08-05T18:02:21Z

IMO it does need an RFC and I am against this specific implementation atm, although I am pleasantly surprised it's possible at all. There might be some value to moving all builtin auto-derives to MIR.

cc @rust-lang/lang @rust-lang/compiler

arielb1 · 2017-08-06T08:05:17Z

@eddyb

What's your problem with the implementation? I think it's pretty clean.

However, we are probably not going to merge this at least before @nikomatsakis returns from vacation next week.

arielb1 · 2017-08-06T08:07:04Z

src/librustc_trans/monomorphize.rs

@@ -143,6 +143,12 @@ fn resolve_associated_item<'a, 'tcx>(
                substs: rcvr_substs
            }
        }
+        traits::VtableBuiltin(ref data) => {
+            Instance {
+                def: ty::InstanceDef::BuiltinShim(def_id, data.ty),


You don't need to store ty anywhere - it is available as trait_ref.self_ty().

eddyb · 2017-08-06T08:08:13Z

@arielb1 My problem is not how it's implemented, but using this method only for some Clone impls. I'd be far more comfortable if all built-in derive impls were moved to MIR shims.

arielb1 · 2017-08-06T08:23:59Z

@eddyb

Because that would mean the code is "tested" more? I'm not so sure on that - it e.g. means we'll have to re-implement error reporting on #[repr(packed)] types, and who knows what else. Also, Clone is still an inductive trait (and must be, because it has a supertrait), so we'll have to do something about the bounds.

arielb1 · 2017-08-07T12:32:36Z

src/librustc/ty/instance.rs

    DropGlue(DefId, Option<Ty<'tcx>>),
+
+    /// Builtin method implementation, e.g. `Clone::clone`.
+    BuiltinShim(DefId, Ty<'tcx>),


Can't this be CloneShim? In other places I have a separate shim class for each trait.

Seems fine, I'll change that.

arielb1 · 2017-08-07T12:37:09Z

src/librustc_mir/shim.rs

+/// Build a `Clone::clone` shim for `recvr_ty`. Here, `def_id` is `Clone::clone`.
+fn build_clone_shim<'a, 'tcx>(tcx: ty::TyCtxt<'a, 'tcx, 'tcx>,
+                              def_id: DefId,
+                              rcvr_ty: ty::Ty<'tcx>)


don't call this rcvr_ty - ty is fine. The receiver is the first argument of the method, which has type &Self (e.g. &[Vec<u32>; 2] if the impl is for <[Vec<u32>; 2] as Clone>. Also fix the comment.

arielb1 · 2017-08-07T12:37:10Z

src/librustc_mir/shim.rs

+/// Build a `Clone::clone` shim for `recvr_ty`. Here, `def_id` is `Clone::clone`.
+fn build_clone_shim<'a, 'tcx>(tcx: ty::TyCtxt<'a, 'tcx, 'tcx>,
+                              def_id: DefId,
+                              rcvr_ty: ty::Ty<'tcx>)


don't call this rcvr_ty - ty is fine. The receiver is the first argument of the method, which has type &Self (e.g. &[Vec<u32>; 2] if the impl is for <[Vec<u32>; 2] as Clone>. Also fix the comment above.

Actually there are too many variables named ty appearing in the code, and I ended up confusing two of them (and having a wrong code generation), that's why I renamed it but I agree rcvr_ty is not ideal, I'll find something else.

Is self_ty fine?

Yup self_ty would be fine.

arielb1 · 2017-08-07T12:39:40Z

src/librustc_mir/shim.rs

+                              rcvr_ty: ty::Ty<'tcx>)
+                              -> Mir<'tcx>
+{
+    let sig = tcx.fn_sig(def_id);


Small note: this is a "fully generic" shim, so it knows the concrete receiver type. You could check if the source type is Copy and emit an "optimized" impl that just copies the result. This will speed up cloning [u8; 1048576] on unoptimized builds and is generally a good idea.

Also, as @eddyb says, it might be a smart idea to plumb #[derive(Clone)] impls through this to avoid implementing the logic twice and to potentially speed up compilation - maybe have #[derive(Clone)] add a #[is_builtin_clone] attribute to the method? I'm not sure.

@arielb1 how would we handle bounds checking? #[derive(Clone)] currently uses local variables of type AssertParamIsClone<T: Clone + ?Sized> for each field type T in order to deal with recursive types. This would not be applicable here.

Actually since we are "fully generic" here as you said, we would could indeed check by hand that the bounds hold for each field type when building the shim.

About plumbing #[derive(Clone)] - we want to give an error on the generic types, before monomorphization, so we can't use this function. So we need a separate checking function - maybe that is not a good idea after all.

arielb1 · 2017-08-07T12:41:16Z

src/librustc_mir/shim.rs

+
+    match rcvr_ty.sty {
+        ty::TyArray(ty, len) => {
+            let mut returns = Vec::new();


I'm worried this might create code explosion for large arrays (think of <[Box<u8>; 1048576]>::clone). Can you try to use a loop and let LLVM unroll it? You're late MIR, so I don't think you have to care about pre-initializing the array.

There is also the possibility to only build a Clone shim for [T; N] where T: Copy, as it's the case already.

I would just write a loop.

arielb1 · 2017-08-07T12:42:44Z

src/librustc_mir/shim.rs

+            func,
+            args: vec![Operand::Consume(ref_loc)],
+            destination: Some((loc.clone(), BasicBlock::new(i + 1))),
+            cleanup: None,


This is wrong - if the drop of a field panics, you need to drop all the previous fields.

It sounds like we have way too many places that try to create their own drop ladders, and we need some sort of unified abstraction.

Right, I was going to ask you about this anyway.

I'll need to write a drop ladder abstraction to help clean this up.

aturon · 2017-08-08T22:47:24Z

From a lang team perspective, I am on board with this change. I don't have an opinion on the compiler side of things.

scalexm · 2017-08-09T12:08:29Z

@arielb1 should be good now

bors · 2017-08-11T15:48:54Z

☔ The latest upstream changes (presumably #43748) made this pull request unmergeable. Please resolve the merge conflicts.

Fixes rust-lang#28229. Fixes rust-lang#24000.

nikomatsakis · 2017-08-21T22:42:07Z

I like the approach. =)

@bors r+

bors · 2017-08-21T22:42:08Z

📌 Commit d58b40e has been approved by nikomatsakis

bors · 2017-08-21T22:46:59Z

⌛ Testing commit d58b40e with merge 31c59189014531ca6f69c95d28add2bd4b2f3647...

bors · 2017-08-21T23:03:53Z

💔 Test failed - status-appveyor

alexcrichton · 2017-08-21T23:05:13Z

@bors: retry

innosetup download failure Tracking issue for Spurious failure for "InnoSetup not installed" on AppVeyor #43985

bors · 2017-08-22T01:35:00Z

⌛ Testing commit d58b40e with merge 942711e...

@nikomatsakis

Generate builtin impls for `Clone` This fixes a long-standing ICE and limitation where some builtin types implement `Copy` but not `Clone` (whereas `Clone` is a super trait of `Copy`). However, this PR has a few side-effects: * `Clone` is now marked as a lang item. * `[T; N]` is now `Clone` if `T: Clone` (currently, only if `T: Copy` and for `N <= 32`). * `fn foo<'a>() where &'a mut (): Clone { }` won't compile anymore because of how bounds for builtin traits are handled (e.g. same thing currently if you replace `Clone` by `Copy` in this example). Of course this function is unusable anyway, an error would pop as soon as it is called. Hence, I'm wondering wether this PR would need an RFC... Also, cc-ing @nikomatsakis, @arielb1. Related issues: #28229, #24000.

bors · 2017-08-22T04:02:41Z

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 942711e to master...

nikomatsakis · 2017-08-22T12:01:31Z

OK, so, I think I was a bit hasty in merging this PR. I thought that the only question at hand was whether it was ok for clone to be a lang-item and for us to generate impls of Clone for types where T: Copy. I have no objection to either of those things. In particular, I feel that the existence of said clone impls is already implied by the language, so we're not "growing" the language by having the compiler synthesizing them, just fixing a bug (in discussion on IRC, @eddyb took an opposite approach, claiming that the bug is that types with no clone impl are considered Copy. This is fair, but changing that would be backwards incompatible, since e.g. [u8; 256] would no longer be copy).

However, reading more carefully, I see that this PR generates clone impls for a few other cases beyond that minimal set. To be fair, these were called out in the PR description. I was just hasty.

For example, prior to the PR, [T; 3] is only Clone if T: Copy (i.e., we use a macro to generate impls, and we only generate them if T: Copy, rather than T: Clone). I don't understand that, but it appears to have been a deliberate decision. Perhaps someone on @rust-lang/libs would care to comment.
Also, I do see a distinction between generating a built-in impl for those cases that are Copy (and hence are required to be Clone for the lang to be consistent) and other types (i.e., impls where we must invoke clone() manually).
- So, for example, making [String; 256] be Clone would fall into the latter category (even ignoring the fact that, today, even [String; 2] is not Clone, since String is not Copy).
- I personally am in favor of such a change, but I do think it ought to have gone through a formal consensus process. I don't see the need necessarily for a full RFC, but rfcbot at least.

For those two reasons, I am thinking that perhaps we should back out this change -- or at least disable it temporarily until we reach a consensus. (And perhaps both libs and lang team ought to be involved, given that [String; 2] is not Clone today?)

alexcrichton · 2017-08-22T14:09:24Z

I'm not sure it was necessarily intentional for [String; 2] to not be Clone AFAIK. The only downside I could think of is that it adds a "huge" amount of IR/metadata bloat for something that doesn't actually work most of the time and is used in vanishingly rare situations.

nikomatsakis · 2017-08-22T14:29:24Z

@alexcrichton

I'm not sure it was necessarily intentional for [String; 2] to not be Clone AFAIK. The only downside I could think of is that it adds a "huge" amount of IR/metadata bloat for something that doesn't actually work most of the time and is used in vanishingly rare situations.

Fair. Of course, under the approach implemented in this PR, that is not an issue.

dtolnay · 2017-08-22T14:45:14Z

(String, String) already implemented Clone. I am on board with [String; 2] implementing Clone, and the other changes listed in the PR description.

…tsakis" This reverts commit 942711e, reversing changes made to 8df670b.

@eddyb

Remove the trait selection impl in method::probe This removes the hacky trait selection reimplementation in `method::probe`, which occasionally comes and causes problems. There are 2 issues I've found with this approach: 1. The older implementation sometimes had a "guess" type from an impl, which allowed subtyping to work. This is why I needed to make a change in `libtest`: there's an `impl<A> Clone for fn(A)` and we're calling `<for<'a> fn(&'a T) as Clone>::clone`. The older implementation would do a subtyping between the impl type and the trait type, so it would do the check for `<fn(A) as Clone>::clone`, and confirmation would continue with the subtyping. The newer implementation directly passes `<for<'a> fn(&'a T) as Clone>::clone` to selection, which fails. I'm not sure how big of a problem that would be in reality, especially after #43690 would remove the `Clone` problem, but I still want a crater run to avoid breaking the world. 2. The older implementation "looked into" impls to display error messages. I'm not sure that's an advantage - it looked exactly 1 level deep. r? @eddyb

bluss · 2017-09-29T16:57:15Z

Tracking issue #44496

Changelog: Version 1.21.0 (2017-10-12) ========================== Language -------- - [You can now use static references for literals.][43838] Example: ```rust fn main() { let x: &'static u32 = &0; } ``` - [Relaxed path syntax. Optional `::` before `<` is now allowed in all contexts.][43540] Example: ```rust my_macro!(Vec<i32>::new); // Always worked my_macro!(Vec::<i32>::new); // Now works ``` Compiler -------- - [Upgraded jemalloc to 4.5.0][43911] - [Enabled unwinding panics on Redox][43917] - [Now runs LLVM in parallel during translation phase.][43506] This should reduce peak memory usage. Libraries --------- - [Generate builtin impls for `Clone` for all arrays and tuples that are `T: Clone`][43690] - [`Stdin`, `Stdout`, and `Stderr` now implement `AsRawFd`.][43459] - [`Rc` and `Arc` now implement `From<&[T]> where T: Clone`, `From<str>`, `From<String>`, `From<Box<T>> where T: ?Sized`, and `From<Vec<T>>`.][42565] Stabilized APIs --------------- [`std::mem::discriminant`] Cargo ----- - [You can now call `cargo install` with multiple package names][cargo/4216] - [Cargo commands inside a virtual workspace will now implicitly pass `--all`][cargo/4335] - [Added a `[patch]` section to `Cargo.toml` to handle prepublication dependencies][cargo/4123] [RFC 1969] - [`include` & `exclude` fields in `Cargo.toml` now accept gitignore like patterns][cargo/4270] - [Added the `--all-targets` option][cargo/4400] - [Using required dependencies as a feature is now deprecated and emits a warning][cargo/4364] Misc ---- - [Cargo docs are moving][43916] to [doc.rust-lang.org/cargo](https://doc.rust-lang.org/cargo) - [The rustdoc book is now available][43863] at [doc.rust-lang.org/rustdoc](https://doc.rust-lang.org/rustdoc) - [Added a preview of RLS has been made available through rustup][44204] Install with `rustup component add rls-preview` - [`std::os` documentation for Unix, Linux, and Windows now appears on doc.rust-lang.org][43348] Previously only showed `std::os::unix`. Compatibility Notes ------------------- - [Changes in method matching against higher-ranked types][43880] This may cause breakage in subtyping corner cases. [A more in-depth explanation is available.][info/43880] - [rustc's JSON error output's byte position start at top of file.][42973] Was previously relative to the rustc's internal `CodeMap` struct which required the unstable library `libsyntax` to correctly use. - [`unused_results` lint no longer ignores booleans][43728] [42565]: rust-lang/rust#42565 [42973]: rust-lang/rust#42973 [43348]: rust-lang/rust#43348 [43459]: rust-lang/rust#43459 [43506]: rust-lang/rust#43506 [43540]: rust-lang/rust#43540 [43690]: rust-lang/rust#43690 [43728]: rust-lang/rust#43728 [43838]: rust-lang/rust#43838 [43863]: rust-lang/rust#43863 [43880]: rust-lang/rust#43880 [43911]: rust-lang/rust#43911 [43916]: rust-lang/rust#43916 [43917]: rust-lang/rust#43917 [44204]: rust-lang/rust#44204 [cargo/4123]: rust-lang/cargo#4123 [cargo/4216]: rust-lang/cargo#4216 [cargo/4270]: rust-lang/cargo#4270 [cargo/4335]: rust-lang/cargo#4335 [cargo/4364]: rust-lang/cargo#4364 [cargo/4400]: rust-lang/cargo#4400 [RFC 1969]: rust-lang/rfcs#1969 [info/43880]: rust-lang/rust#44224 (comment) [`std::mem::discriminant`]: https://doc.rust-lang.org/std/mem/fn.discriminant.html

This should be the relevant issue: rust-lang/rust#43690.

rust-highfive assigned eddyb Aug 5, 2017

arielb1 reviewed Aug 6, 2017

View reviewed changes

arielb1 reviewed Aug 7, 2017

View reviewed changes

arielb1 added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 8, 2017

scalexm force-pushed the issue-28229 branch 2 times, most recently from 7370f8f to 779d2c5 Compare August 8, 2017 18:13

scalexm added 8 commits August 14, 2017 15:07

Make Clone a lang item and generate builtin impls.

0c3ac64

Fixes rust-lang#28229. Fixes rust-lang#24000.

Remove dummy lang items

f55dafe

Add a test

91e99a3

Do not store ty

91aa996

Rename BuiltinShim -> CloneShim

4e4e55a

Optimize clone shim for Copy types

df7be43

Handle unwinding, use a loop for arrays

e1f1798

Use an helper struct

d58b40e

scalexm force-pushed the issue-28229 branch from 0d108eb to d58b40e Compare August 14, 2017 13:07

arielb1 mentioned this pull request Aug 15, 2017

Remove the trait selection impl in method::probe #43880

Merged

nikomatsakis self-assigned this Aug 21, 2017

bors merged commit d58b40e into rust-lang:master Aug 22, 2017

bors mentioned this pull request Aug 22, 2017

Generator support #43076

Merged

7 tasks

bluss added the relnotes Marks issues that should be documented in the release notes of the next release. label Aug 22, 2017

arielb1 added a commit to arielb1/rust that referenced this pull request Aug 22, 2017

Revert "Auto merge of rust-lang#43690 - scalexm:issue-28229, r=nikoma…

1e36d0b

…tsakis" This reverts commit 942711e, reversing changes made to 8df670b.

arielb1 mentioned this pull request Aug 22, 2017

Revert "Auto merge of #43690 - scalexm:issue-28229, r=nikomatsakis" #44045

Closed

killercup mentioned this pull request Aug 23, 2017

September 2017 Rustaceans/rust-cologne#37

Closed

10 tasks

RalfJung mentioned this pull request Aug 23, 2017

implement built-in Clone rust-lang/miri#307

Closed

This was referenced Aug 28, 2017

Copy/Clone Closures rust-lang/rfcs#2132

Merged

Make Clone a lang-item and implement it for closures whose members are all Clone rust-lang/rfcs#1369

Closed

scalexm mentioned this pull request Aug 30, 2017

RFC - compiler-generated Clone impls for Arrays and Tuples rust-lang/rfcs#2133

Merged

dimbleby mentioned this pull request Oct 13, 2017

Derive Clone when deriving Copy rust-lang/rust-bindgen#934

Closed

hcpl added a commit to hcpl/zalgo.rs that referenced this pull request Apr 9, 2018

Remove a [derive(Clone)] for Rust 1.20

ab74dfd

This should be the relevant issue: rust-lang/rust#43690.

scalexm deleted the issue-28229 branch October 22, 2018 12:18

Navigation Menu

Generate builtin impls for Clone #43690

Generate builtin impls for Clone #43690

Conversation

scalexm commented Aug 5, 2017

rust-highfive commented Aug 5, 2017

eddyb commented Aug 5, 2017

arielb1 commented Aug 6, 2017

Choose a reason for hiding this comment

eddyb commented Aug 6, 2017

arielb1 commented Aug 6, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arielb1 Aug 7, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arielb1 Aug 7, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aturon commented Aug 8, 2017

scalexm commented Aug 9, 2017

bors commented Aug 11, 2017

nikomatsakis commented Aug 21, 2017

bors commented Aug 21, 2017

bors commented Aug 21, 2017

bors commented Aug 21, 2017

alexcrichton commented Aug 21, 2017

bors commented Aug 22, 2017

bors commented Aug 22, 2017

nikomatsakis commented Aug 22, 2017

alexcrichton commented Aug 22, 2017

nikomatsakis commented Aug 22, 2017

dtolnay commented Aug 22, 2017

bluss commented Sep 29, 2017

Generate builtin impls for `Clone` #43690

Generate builtin impls for `Clone` #43690

arielb1 commented Aug 6, 2017 •

edited

arielb1 Aug 7, 2017 •

edited

arielb1 Aug 7, 2017 •

edited