Mojom structs for copy requests / results should map to unique_ptr

cc/ipc/copy_output_request_struct_traits.cc

Index: cc/ipc/copy_output_request_struct_traits.cc
diff --git a/cc/ipc/copy_output_request_struct_traits.cc b/cc/ipc/copy_output_request_struct_traits.cc
new file mode 100644
index 0000000000000000000000000000000000000000..246f73f43625c7c16473e2288398cf36bcf2f54e
--- /dev/null
+++ b/cc/ipc/copy_output_request_struct_traits.cc
@@ -0,0 +1,21 @@
+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "cc/ipc/copy_output_request_struct_traits.h"
+
+namespace mojo {
+
+// static
+bool StructTraits<cc::mojom::CopyOutputRequestDataView,
+                  std::unique_ptr<cc::CopyOutputRequest>>::
+    Read(cc::mojom::CopyOutputRequestDataView data,
+         std::unique_ptr<cc::CopyOutputRequest>* out_p) {
+  std::unique_ptr<cc::CopyOutputRequest>& out = *out_p;
+  out = cc::CopyOutputRequest::CreateEmptyRequest();
+  out->force_bitmap_result_ = data.force_bitmap_result();
+  return data.ReadSource(&out->source_) && data.ReadArea(&out->area_) &&

[Tom Sepez, 2017/02/04 00:32:14]

I suppose it's ok to short-circuit here, the caller will free the object
eventually even though its only partially-filled in.

This is going to come up over and again when reviewing these, is there a
precedent for keeping the unique_ptr local to immediately clean up on error and
then std::move() it at the end?  I'd argue for such a thing, but I can see that
is isn't strictly necesary.

[Saman Sami, 2017/02/04 01:09:25]

Good idea. It'll make the code cleaner too. Here is something similar in the
code base:
https://cs.chromium.org/chromium/src/ui/display/mojo/display_layout_struct_tr...

+         data.ReadTextureMailbox(&out->texture_mailbox_);
+}
+
+}  // namespace mojo