special-case #[derive(Copy, Clone)] with a shallow clone #31414

durka · 2016-02-04T20:51:37Z

If a type is Copy then its Clone implementation can be a no-op. Currently #[derive(Clone)] generates a deep clone anyway. This can lead to lots of code bloat.

This PR detects the case where Copy and Clone are both being derived (the general case of "is this type Copy" can't be determined by a syntax extension) and generates the shallow Clone impl. Right now this can only be done if there are no type parameters (see #31085 (comment)), but this restriction can be removed after specialization.

Fixes #31085.

rust-highfive · 2016-02-04T20:51:50Z

r? @brson

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

nagisa · 2016-02-04T21:01:06Z

src/libsyntax_ext/deriving/clone.rs

+                ast::ItemStruct(_, ast::Generics { ref ty_params, .. })
+                    | ast::ItemEnum(_, ast::Generics { ref ty_params, .. })
+                    if ty_params.is_empty()
+                        && (|| item.attrs.iter().any(|a| a.name() == "derive_Copy"))() => {


syntax::attr::contains_name(item.attrs, "derive_Copy")

bluss · 2016-02-04T21:16:36Z

According to #31085 (comment) this kind of improvement can improve compile times (that's a case with a lot of structs).

According to me @ #31085 (comment) using the Copy-based clone can improve codegen for loops calling .clone().

bors · 2016-02-05T17:15:38Z

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

durka · 2016-02-05T19:29:17Z

It occurs to me that the shallow Clone can also be done in this situation:

#[derive(Copy, Clone)]
struct S<T: Copy>(T);

i.e. when there are generic parameters but they are all already constrained to be Copy. Is it worth it to add this check as well?

Edit: seems like it would be somewhat unworkably unhygienic. We'd have to check for the literal name "Copy", since all this happens before resolve.

durka · 2016-02-05T21:50:35Z

Rebased.

nagisa · 2016-02-05T21:53:17Z

This PR LGTM, but I’d like an opinion from somebody more familiar with the code as well.

brson · 2016-02-05T23:38:46Z

src/test/run-make/pretty-expanded-hygiene/input.rs

+
+#[derive(Copy, Clone)]
+struct B<T> { a: T }
+


Can you put this in its own rmake test case instead of piggy-backing on this one?

I'll split the tests and revert my changes to the Makefile for this one.

brson · 2016-02-05T23:43:38Z

Do we have any concrete numbers that this gives to either compile time or runtime? @retep998 said he worked around this on winapi because of bad compile times. Perhaps we can change winapi to use deriving again and see if this improves perf there.

durka · 2016-02-05T23:49:06Z

Travis failed because I didn't run the full test suite locally. Will fix later tonight.

durka · 2016-02-06T07:44:12Z

I split the tests and tried to fix the fallout in the rpass-full tests. I'm getting linker errors locally which I think will be solved by make clean, we'll see.

durka · 2016-02-06T20:57:06Z

@brson @bluss here are the runtime benchmarks: gist

The performance of clone_from_slice on #[derive(Copy, Clone)] struct S(u8, u32); is doubled.

durka · 2016-02-06T21:08:38Z

@brson @retep998 and compile time: gist

A #[derive(Copy, Clone)] struct with 1000 members compiles 13 times faster.

durka · 2016-02-06T22:58:57Z

As a bonus, this extends the reach of #[derive(Clone)] -- you can now #[derive(Copy, Clone)] on structs containing types which are Copy but not Clone, such as [u8; 100]. gist

bluss · 2016-02-06T23:04:45Z

Compile time win for structs and enums might be the best thing with this. A bit unnerving that it enables deriving Clone on more things, though. That makes it hard to go back on this optimization.

durka · 2016-02-06T23:53:21Z

@bluss I don't see why we'd want to go back on it. Plus, more motivation to fix the issue where types can be magically Copy but not Clone :)

brson · 2016-02-07T00:06:20Z

Wow, great numbers.

I'm also uneasy about the semantic change this brings, making derive Copy/Clone work on types containing those that aren't clone. It exposes the optimization - semantically we may actually want derive Clone to be defined as if it was implemented the naive way.

I assume this doesn't magically make just derive(Clone) work for types containing types that don't implement Clone, but only derive(Copy, Clone), and that's super weird.

durka · 2016-02-07T00:17:04Z

I assume this doesn't magically make just derive(Clone) work for types containing types that don't implement Clone, but only derive(Copy, Clone)

Correct. The derives just do their little syntactical shufflings and leave it to typeck to enforce the constraints later.

and that's super weird.

I agree, but it's only observable if you have a type that's Copy and not Clone, which isn't supposed to be possible. So it only comes up with corner cases like arrays over size 32 or tuples over size 12.

durka · 2016-02-07T00:20:18Z

We could revert the semantic change by generating code like this:

impl Clone for Foo {
    fn clone(&self) -> Foo {
        if false { /* naive implementation */ }
        else { *self }
    }
}

but we'd of course lose the compile-time wins.

sfackler · 2016-02-07T16:26:44Z

I think we optimize if false ... in the frontend so that branch would at least not make it to LLVM.

Can't we also do something like

struct Foo {
    bar: Bar,
}

// generated
impl Clone for Foo {
    fn clone(&self) -> Foo {
        fn is_clone<C: Clone>() {}
        is_clone::<Bar>();
        *self
    }
}

which should avoid the compile time sadness.

sfackler · 2016-02-07T16:27:52Z

That does still leave the behavior change that bar's Clone impl isn't invoked obviously.

durka · 2016-02-07T18:47:17Z

@sfackler I'm trying this. I still think it's insignificant since the existence of T: Copy + !Clone is a bug.

eddyb · 2016-04-22T21:35:17Z

@durka Good question, it would likely make winapi worse, not better. Maybe replace #[derive(Copy, Clone)] with #[derive_CopyClone] or something like that?

durka · 2016-04-22T23:39:25Z

@Manishearth sorry about my slowness. I still need to fix the spans so I
can make core::assert_receiver_is_clone unstable. And I was hoping if I
stared at the deriving code long enough I could remove the breakage, but I
don't see how. So punt on this if you want, otherwise I'll really try to
get it ready to land this weekend.
On Apr 22, 2016 17:36, "Eduard-Mihai Burtescu" notifications@github.com
wrote:

@durka https://github.com/durka Good question, it would likely make
winapi worse, not better. Maybe replace #[derive(Copy, Clone)] with
#[derive_CopyClone] or something like that?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#31414 (comment)

Manishearth · 2016-04-22T23:41:28Z

Nah, it's okay, we can wait a few days 😄

I wasn't sure what the status of this PR was.

retep998 · 2016-04-23T01:51:03Z

@eddyb I don't use #[derive(Clone)] at all in winapi.

durka · 2016-04-23T14:56:29Z

@retep998 but you could in a parallel universe where #[derive(Clone)]
didn't slow things down and winapi didn't care about 1.x backcompat.
On Apr 22, 2016 21:51, "Peter Atashian" notifications@github.com wrote:

@eddyb https://github.com/eddyb I don't use #[derive(Clone)] at all in
winapi.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#31414 (comment)

retep998 · 2016-04-23T15:08:57Z

@durka But I can't due some Copy types not being Clone such as function pointers and large arrays which winapi has quite a lot of.

bluss · 2016-04-23T15:11:50Z

How lovely, winapi needs the bugs that this PR takes care to not expose. 😄 Can't please them all

durka · 2016-04-24T04:00:26Z

The stage1-rmake test passes now. And the stage2-rpass-full one. And I guess travis will try them all.

durka · 2016-04-24T04:15:08Z

@eddyb and I are now certain we can do this without the breaking change. un-cc #31645 and my apologies for delaying the batch :)

durka · 2016-04-25T02:08:02Z

Breaking change removed. Performance gains retained.

alexcrichton · 2016-04-25T17:41:02Z

src/test/run-pass/issue-3121.rs

@@ -8,7 +8,7 @@
 // option. This file may not be copied, modified, or distributed
 // except according to those terms.

-// pretty-expanded FIXME #23616
+// no-pretty-expanded FIXME #23616 assert_receiver_is_clone


Instead of no-pretty-expanded I think you can just remove these directives altogether

Oh is it opt-in? Ok. I thought it was opt-out. I also figured if I left the mention of the method name here, then someone in the future stabilizing or removing this hack might grep for it and realize they could re-enable the test. But it's fine with me to remove it.

Nah yeah it's fine to just remove everywhere, right now that phase of testing is opt-in

Fair enough. Does that mean when I write a new run-pass test I should try
to add "// pretty-expanded"? Do we have a policy on that?

On Mon, Apr 25, 2016 at 2:24 PM, Alex Crichton notifications@github.com
wrote:

In src/test/run-pass/issue-3121.rs
#31414 (comment):

@@ -8,7 +8,7 @@
// option. This file may not be copied, modified, or distributed
// except according to those terms.

-// pretty-expanded FIXME #23616
+// no-pretty-expanded FIXME #23616 assert_receiver_is_clone

Nah yeah it's fine to just remove everywhere, right now that phase of
testing is opt-in

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/rust-lang/rust/pull/31414/files/64d22d453d5b71b33b149dac3c28b2d626446d9f#r60962453

Nah it's fine to just remove these comments

alexcrichton · 2016-04-26T17:06:14Z

Thanks again for the PR @durka! Everything looks good to me, wanna squash and I'll r+?

durka · 2016-04-26T17:35:22Z

Squashed and wrote a more extensive commit message.

On Tue, Apr 26, 2016 at 1:06 PM, Alex Crichton notifications@github.com
wrote:

Thanks again for the PR @durka https://github.com/durka! Everything
looks good to me, wanna squash and I'll r+?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#31414 (comment)

Changes #[derive(Copy, Clone)] to use a faster impl of Clone when both derives are present, and there are no generics in the type. The faster impl is simply returning *self (which works because the type is also Copy). See the comments in libsyntax_ext/deriving/clone.rs for more details. There are a few types which are Copy but not Clone, in violation of the definition of Copy. These include large arrays and tuples. The very existence of these types is arguably a bug, but in order for this optimization not to change the applicability of #[derive(Copy, Clone)], the faster Clone impl also injects calls to a new function, core::clone::assert_receiver_is_clone, to verify that all members are actually Clone. This is not a breaking change, because pursuant to RFC 1521, any type that implements Copy should not do any observable work in its Clone impl.

alexcrichton · 2016-04-26T21:49:02Z

@bors: r+ 9249e6a

special-case #[derive(Copy, Clone)] with a shallow clone If a type is Copy then its Clone implementation can be a no-op. Currently `#[derive(Clone)]` generates a deep clone anyway. This can lead to lots of code bloat. This PR detects the case where Copy and Clone are both being derived (the general case of "is this type Copy" can't be determined by a syntax extension) and generates the shallow Clone impl. Right now this can only be done if there are no type parameters (see #31085 (comment)), but this restriction can be removed after specialization. Fixes #31085.

bors · 2016-04-26T21:54:38Z

⌛ Testing commit 9249e6a with merge 8f55218...

bors · 2016-04-27T00:01:47Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-32cross-opt, auto-linux-64-cargotest, auto-linux-64-cross-armhf, auto-linux-64-cross-armsf, auto-linux-64-cross-freebsd, auto-linux-64-cross-netbsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-cross-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-mir, auto-win-msvc-64-opt-rustbuild

rust-highfive assigned brson Feb 4, 2016

durka mentioned this pull request Feb 4, 2016

#[derive(Clone)] should rely on Copy when possible #31085

Closed

durka force-pushed the clone-copy branch from 69cb84b to 0aaacb3 Compare February 4, 2016 20:52

durka changed the title ~~special-case #[derive(Copy, Clone)] with a shallow copy~~ special-case #[derive(Copy, Clone)] with a shallow clone Feb 4, 2016

nagisa reviewed Feb 4, 2016
View reviewed changes

durka force-pushed the clone-copy branch from 0aaacb3 to fe59b7c Compare February 5, 2016 21:49

brson reviewed Feb 5, 2016
View reviewed changes

brson added the relnotes Marks issues that should be documented in the release notes of the next release. label Feb 5, 2016

durka force-pushed the clone-copy branch from fe59b7c to 298ddac Compare February 6, 2016 07:43

durka force-pushed the clone-copy branch from 6712c02 to 5d800cb Compare April 24, 2016 03:55

durka force-pushed the clone-copy branch from e54419a to 33c1c86 Compare April 25, 2016 02:05

durka force-pushed the clone-copy branch from 33c1c86 to 64d22d4 Compare April 25, 2016 02:18

alexcrichton reviewed Apr 25, 2016
View reviewed changes

durka force-pushed the clone-copy branch from b47ffb4 to 1e82084 Compare April 26, 2016 03:47

durka force-pushed the clone-copy branch from c8ae7ee to 34b7575 Compare April 26, 2016 17:34

durka force-pushed the clone-copy branch from 34b7575 to 9249e6a Compare April 26, 2016 17:49

bors merged commit 9249e6a into rust-lang:master Apr 27, 2016

leoyvens mentioned this pull request Jun 12, 2016

Clippy run and derive Default for Buffer hyperium/hyper#817

Merged

petrochenkov mentioned this pull request Aug 27, 2016

Support #[derive(Copy, Clone)] and #[derive(Clone)] for unions with Copy fields #36043

Closed

petrochenkov mentioned this pull request Sep 11, 2016

Improve shallow Clone deriving #36384

Merged

mcarton mentioned this pull request Oct 8, 2016

Improved Clone derive mcarton/rust-derivative#2

Closed

3 tasks

special-case #[derive(Copy, Clone)] with a shallow clone #31414

special-case #[derive(Copy, Clone)] with a shallow clone #31414

Conversation

durka commented Feb 4, 2016 • edited Loading

rust-highfive commented Feb 4, 2016

Choose a reason for hiding this comment

bluss commented Feb 4, 2016

bors commented Feb 5, 2016

durka commented Feb 5, 2016

durka commented Feb 5, 2016

nagisa commented Feb 5, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brson commented Feb 5, 2016

durka commented Feb 5, 2016

durka commented Feb 6, 2016

durka commented Feb 6, 2016

durka commented Feb 6, 2016

durka commented Feb 6, 2016

bluss commented Feb 6, 2016

durka commented Feb 6, 2016

brson commented Feb 7, 2016

durka commented Feb 7, 2016

durka commented Feb 7, 2016

sfackler commented Feb 7, 2016

sfackler commented Feb 7, 2016

durka commented Feb 7, 2016

eddyb commented Apr 22, 2016

durka commented Apr 22, 2016

Manishearth commented Apr 22, 2016

retep998 commented Apr 23, 2016

durka commented Apr 23, 2016

retep998 commented Apr 23, 2016 • edited Loading

bluss commented Apr 23, 2016

durka commented Apr 24, 2016 • edited Loading

durka commented Apr 24, 2016

durka commented Apr 25, 2016

Choose a reason for hiding this comment

durka Apr 25, 2016 • edited Loading

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

alexcrichton commented Apr 26, 2016

durka commented Apr 26, 2016

alexcrichton commented Apr 26, 2016

bors commented Apr 26, 2016

bors commented Apr 27, 2016

durka commented Feb 4, 2016 •

edited

Loading

retep998 commented Apr 23, 2016 •

edited

Loading

durka commented Apr 24, 2016 •

edited

Loading

durka Apr 25, 2016 •

edited

Loading