Use std::default_delete as the default deleter for scoped_ptr.

Use std::default_delete as the default deleter for scoped_ptr.

The aim is to make scoped_ptr and std::unique_ptr functionally
identical so scoped_ptr can simply be a typedef.

BUG=554298
Committed: https://crrev.com/0917ec4328dc20b59887d78f76b9f075e12e5f7f
Cr-Commit-Position: refs/heads/master@{#360539}

[dcheng, 2015-11-16 18:20:56]

Description was changed from

==========
Use std::default_delete as the default deleter for scoped_ptr.

BUG=554298
==========

to

==========
Use std::default_delete as the default deleter for scoped_ptr.

The aim is to make scoped_ptr and std::unique_ptr functionally
identical so scoped_ptr can simply be a typedef.

BUG=554298
==========

[dcheng, 2015-11-16 18:20:56]

dcheng@chromium.org changed reviewers:
+ danakj@chromium.org, thakis@chromium.org

[dcheng, 2015-11-16 18:22:59]

Given that reference qualifiers don't work in VS2013 (see
https://codereview.chromium.org/1432193002#msg4: I verified that reference
qualifiers trigger a compile error in VS2013), this is my alternate proposal. It
changes scoped_ptr to use the same default deleter as std::unique_ptr.

There are still a few Windows compile issues I need to work out, but this patch
should give a pretty good overall view of what the changes will look like.

Another question: should I send out a proposal to allow use of
std::default_delete? Or is this an internal-enough detail that people probably
don't need to care?

https://codereview.chromium.org/1445003002/diff/120001/base/memory/scoped_ptr.h
File base/memory/scoped_ptr.h (right):

https://codereview.chromium.org/1445003002/diff/120001/base/memory/scoped_ptr...
base/memory/scoped_ptr.h:89: #include <utility>
In line with bratell@'s proposal to #include <utility> instead of <algorithm>, I
went ahead and just changed it here (since it's included so widely).

https://codereview.chromium.org/1445003002/diff/120001/base/trace_event/memor...
File base/trace_event/memory_dump_manager.h (right):

https://codereview.chromium.org/1445003002/diff/120001/base/trace_event/memor...
base/trace_event/memory_dump_manager.h:128: friend
std::default_delete<MemoryDumpManager>;  // For the testing instance.
This is a C++11-ism. Do we want to stick with:
friend struct std::default_delete<MemoryDumpManager>;?

https://codereview.chromium.org/1445003002/diff/120001/chrome/browser/extensi...
File
chrome/browser/extensions/api/webrtc_audio_private/webrtc_audio_private_api.cc
(right):

https://codereview.chromium.org/1445003002/diff/120001/chrome/browser/extensi...
chrome/browser/extensions/api/webrtc_audio_private/webrtc_audio_private_api.cc:126:
base::Passed(&device_names)));
I have no idea how this compiled before.

https://codereview.chromium.org/1445003002/diff/120001/chromeos/dbus/fake_mod...
File chromeos/dbus/fake_modem_messaging_client.cc (right):

https://codereview.chromium.org/1445003002/diff/120001/chromeos/dbus/fake_mod...
chromeos/dbus/fake_modem_messaging_client.cc:7: #include <algorithm>
All the lines like this are because people were depending on the <algorithm>
include in scoped_ptr.h.

https://codereview.chromium.org/1445003002/diff/120001/content/browser/servic...
File content/browser/service_worker/service_worker_process_manager.cc (right):

https://codereview.chromium.org/1445003002/diff/120001/content/browser/servic...
content/browser/service_worker/service_worker_process_manager.cc:274: void
default_delete<content::ServiceWorkerProcessManager>::operator()(
This is permitted by the C++ standard but probably looks a bit wonky. From
http://en.cppreference.com/w/cpp/language/extending_std:

"It is allowed to add template specializations for any standard library template
to the namespace std only if the declaration depends on a user-defined type and
the specialization satisfies all requirements for the original template, except
where such specializations are prohibited."

[danakj, 2015-11-16 22:19:03]

https://codereview.chromium.org/1445003002/diff/120001/base/memory/scoped_ptr.h
File base/memory/scoped_ptr.h (left):

https://codereview.chromium.org/1445003002/diff/120001/base/memory/scoped_ptr...
base/memory/scoped_ptr.h:153: // Never allow someone to declare something like
scoped_ptr<int[10]>.
Is this check provided by libc++ somewhere? Should we implement something to
watch for this in clang/plugin or presubmit?

https://codereview.chromium.org/1445003002/diff/120001/base/memory/scoped_ptr...
base/memory/scoped_ptr.h:235: assert(!ShouldAbortOnSelfReset<D>::value || p ==
nullptr || p != data_.ptr);
I'm not sure why this went away in this CL TBH. I agree about making things
match, but using std::default_delete doesn't change our expectations here at
all, does it?

https://codereview.chromium.org/1445003002/diff/120001/base/memory/scoped_ptr.h
File base/memory/scoped_ptr.h (right):

https://codereview.chromium.org/1445003002/diff/120001/base/memory/scoped_ptr...
base/memory/scoped_ptr.h:125: struct ShouldAbortOnSelfReset {
Does this go away then?

https://codereview.chromium.org/1445003002/diff/120001/base/memory/scoped_ptr...
base/memory/scoped_ptr.h:127: static NoType Test(const typename
U::AllowSelfReset*);
And any instances of AllowSelfReset in the codebase?

https://codereview.chromium.org/1445003002/diff/120001/base/trace_event/memor...
File base/trace_event/memory_dump_manager.h (right):

https://codereview.chromium.org/1445003002/diff/120001/base/trace_event/memor...
base/trace_event/memory_dump_manager.h:128: friend
std::default_delete<MemoryDumpManager>;  // For the testing instance.
On 2015/11/16 18:22:59, dcheng wrote:
> This is a C++11-ism. Do we want to stick with:
> friend struct std::default_delete<MemoryDumpManager>;?

Seems ok if the bots work. I have some vague memory that this doesn't work on
win yet? But the current fails look like missing headers.

https://codereview.chromium.org/1445003002/diff/120001/chrome/browser/chromeo...
File chrome/browser/chromeos/app_mode/kiosk_app_manager.h (right):

https://codereview.chromium.org/1445003002/diff/120001/chrome/browser/chromeo...
chrome/browser/chromeos/app_mode/kiosk_app_manager.h:232: friend
std::default_delete<KioskAppManager>;
This seems like a weird pattern, and I'd expect instead to have the destructor
public and the constructor private with a Create() that returns a unique_ptr or
something. But I guess this is how it is.

https://codereview.chromium.org/1445003002/diff/120001/chromeos/dbus/fake_mod...
File chromeos/dbus/fake_modem_messaging_client.cc (right):

https://codereview.chromium.org/1445003002/diff/120001/chromeos/dbus/fake_mod...
chromeos/dbus/fake_modem_messaging_client.cc:7: #include <algorithm>
On 2015/11/16 18:22:59, dcheng wrote:
> All the lines like this are because people were depending on the <algorithm>
> include in scoped_ptr.h.

Silly compilers.

https://codereview.chromium.org/1445003002/diff/120001/content/browser/servic...
File content/browser/service_worker/service_worker_process_manager.cc (right):

https://codereview.chromium.org/1445003002/diff/120001/content/browser/servic...
content/browser/service_worker/service_worker_process_manager.cc:274: void
default_delete<content::ServiceWorkerProcessManager>::operator()(
On 2015/11/16 18:22:59, dcheng wrote:
> This is permitted by the C++ standard but probably looks a bit wonky. From
> http://en.cppreference.com/w/cpp/language/extending_std:
> 
> "It is allowed to add template specializations for any standard library
template
> to the namespace std only if the declaration depends on a user-defined type
and
> the specialization satisfies all requirements for the original template,
except
> where such specializations are prohibited."

Oh.. thanks for the linky!

Why is this written as a function overload, but the previous one is written as a
template specialization?

https://codereview.chromium.org/1445003002/diff/120001/ui/base/x/x11_menu_lis...
File ui/base/x/x11_menu_list.cc (right):

https://codereview.chromium.org/1445003002/diff/120001/ui/base/x/x11_menu_lis...
ui/base/x/x11_menu_list.cc:7: #include <algorithm>
need whitespace between <> and "" includes?

[dcheng, 2015-11-17 17:08:42]

https://codereview.chromium.org/1445003002/diff/120001/base/memory/scoped_ptr.h
File base/memory/scoped_ptr.h (left):

https://codereview.chromium.org/1445003002/diff/120001/base/memory/scoped_ptr...
base/memory/scoped_ptr.h:153: // Never allow someone to declare something like
scoped_ptr<int[10]>.
On 2015/11/16 at 22:19:02, danakj (behind on reviews) wrote:
> Is this check provided by libc++ somewhere? Should we implement something to
watch for this in clang/plugin or presubmit?

It's not explicitly provided by libc++. For example, this compiles:
  std::unique_ptr<int[5]> p;

But this does not:
  std::unique_ptr<int[5]> a(new int[5]);

(Like many C++ warnings, the compiler error can be cast around, but hopefully if
someone's doing that, they're going to have second thoughts after writing the
cast...)

So I think we're OK in that department.

https://codereview.chromium.org/1445003002/diff/120001/base/memory/scoped_ptr...
base/memory/scoped_ptr.h:235: assert(!ShouldAbortOnSelfReset<D>::value || p ==
nullptr || p != data_.ptr);
On 2015/11/16 at 22:19:02, danakj (behind on reviews) wrote:
> I'm not sure why this went away in this CL TBH. I agree about making things
match, but using std::default_delete doesn't change our expectations here at
all, does it?

This is just making the interface match std::unique_ptr more closely. The type
trait we use to detect this currently isn't implemented at all by libc++, nor is
the check.

If you feel strongly about this, I could make this select on whether or not the
default deleter is being used.

https://codereview.chromium.org/1445003002/diff/120001/base/memory/scoped_ptr.h
File base/memory/scoped_ptr.h (right):

https://codereview.chromium.org/1445003002/diff/120001/base/memory/scoped_ptr...
base/memory/scoped_ptr.h:125: struct ShouldAbortOnSelfReset {
On 2015/11/16 at 22:19:02, danakj (behind on reviews) wrote:
> Does this go away then?

Yes, it should.

https://codereview.chromium.org/1445003002/diff/120001/base/memory/scoped_ptr...
base/memory/scoped_ptr.h:127: static NoType Test(const typename
U::AllowSelfReset*);
On 2015/11/16 at 22:19:02, danakj (behind on reviews) wrote:
> And any instances of AllowSelfReset in the codebase?

Good catch, I forgot that there's some code in //net using it (kind of
embarrassing since I think I'm the one that was involved in writing this).

https://codereview.chromium.org/1445003002/diff/120001/content/browser/servic...
File content/browser/service_worker/service_worker_process_manager.cc (right):

https://codereview.chromium.org/1445003002/diff/120001/content/browser/servic...
content/browser/service_worker/service_worker_process_manager.cc:274: void
default_delete<content::ServiceWorkerProcessManager>::operator()(
On 2015/11/16 at 22:19:03, danakj (behind on reviews) wrote:
> On 2015/11/16 18:22:59, dcheng wrote:
> > This is permitted by the C++ standard but probably looks a bit wonky. From
> > http://en.cppreference.com/w/cpp/language/extending_std:
> > 
> > "It is allowed to add template specializations for any standard library
template
> > to the namespace std only if the declaration depends on a user-defined type
and
> > the specialization satisfies all requirements for the original template,
except
> > where such specializations are prohibited."
> 
> Oh.. thanks for the linky!
> 
> Why is this written as a function overload, but the previous one is written as
a template specialization?

This is the definition of operator() in the previous template specialization.

https://codereview.chromium.org/1445003002/diff/120001/ui/base/x/x11_menu_lis...
File ui/base/x/x11_menu_list.cc (right):

https://codereview.chromium.org/1445003002/diff/120001/ui/base/x/x11_menu_lis...
ui/base/x/x11_menu_list.cc:7: #include <algorithm>
On 2015/11/16 at 22:19:03, danakj (behind on reviews) wrote:
> need whitespace between <> and "" includes?

Done.

[danakj, 2015-11-17 19:09:27]

LGTM

https://codereview.chromium.org/1445003002/diff/120001/base/memory/scoped_ptr.h
File base/memory/scoped_ptr.h (left):

https://codereview.chromium.org/1445003002/diff/120001/base/memory/scoped_ptr...
base/memory/scoped_ptr.h:235: assert(!ShouldAbortOnSelfReset<D>::value || p ==
nullptr || p != data_.ptr);
On 2015/11/17 17:08:42, dcheng wrote:
> On 2015/11/16 at 22:19:02, danakj (behind on reviews) wrote:
> > I'm not sure why this went away in this CL TBH. I agree about making things
> match, but using std::default_delete doesn't change our expectations here at
> all, does it?
> 
> This is just making the interface match std::unique_ptr more closely. The type
> trait we use to detect this currently isn't implemented at all by libc++, nor
is
> the check.
> 
> If you feel strongly about this, I could make this select on whether or not
the
> default deleter is being used.

Yah, I kinda figured this would make a reasonable separate CL. Cuz
ShouldAbortOnSelfReset would work with default_delete too, right? Anyways, it
needs to go at some point so this is fine.

https://codereview.chromium.org/1445003002/diff/120001/content/browser/servic...
File content/browser/service_worker/service_worker_process_manager.cc (right):

https://codereview.chromium.org/1445003002/diff/120001/content/browser/servic...
content/browser/service_worker/service_worker_process_manager.cc:274: void
default_delete<content::ServiceWorkerProcessManager>::operator()(
On 2015/11/17 17:08:42, dcheng wrote:
> On 2015/11/16 at 22:19:03, danakj (behind on reviews) wrote:
> > On 2015/11/16 18:22:59, dcheng wrote:
> > > This is permitted by the C++ standard but probably looks a bit wonky. From
> > > http://en.cppreference.com/w/cpp/language/extending_std:
> > > 
> > > "It is allowed to add template specializations for any standard library
> template
> > > to the namespace std only if the declaration depends on a user-defined
type
> and
> > > the specialization satisfies all requirements for the original template,
> except
> > > where such specializations are prohibited."
> > 
> > Oh.. thanks for the linky!
> > 
> > Why is this written as a function overload, but the previous one is written
as
> a template specialization?
> 
> This is the definition of operator() in the previous template specialization.

Er, oh yes. Magnets..

https://codereview.chromium.org/1445003002/diff/160001/crypto/scoped_nss_types.h
File crypto/scoped_nss_types.h (left):

https://codereview.chromium.org/1445003002/diff/160001/crypto/scoped_nss_type...
crypto/scoped_nss_types.h:19: typedef void AllowSelfReset;
Can you maybe replace each of these AllowSelfReset with a comment saying that
this destroyer was written in a way that will allow self reset?

https://codereview.chromium.org/1445003002/diff/160001/mojo/shell/data_pipe_p...
File mojo/shell/data_pipe_peek.cc (right):

https://codereview.chromium.org/1445003002/diff/160001/mojo/shell/data_pipe_p...
mojo/shell/data_pipe_peek.cc:8: #include <algorithm>
whitespace between these (cuz they are diff sets and not sorted together)

https://codereview.chromium.org/1445003002/diff/160001/ui/gfx/animation/linea...
File ui/gfx/animation/linear_animation.cc (right):

https://codereview.chromium.org/1445003002/diff/160001/ui/gfx/animation/linea...
ui/gfx/animation/linear_animation.cc:8: #include <algorithm>
+whitespace

[dcheng, 2015-11-17 20:14:17]

dcheng@chromium.org changed reviewers:
+ brettw@chromium.org

[dcheng, 2015-11-17 20:14:18]

+brettw for global approval

(Addressing the code review comments now)

[dcheng, 2015-11-17 20:21:02]

dcheng@chromium.org changed reviewers:
+ davidben@chromium.org

[dcheng, 2015-11-17 20:21:03]

https://codereview.chromium.org/1445003002/diff/160001/crypto/scoped_nss_types.h
File crypto/scoped_nss_types.h (left):

https://codereview.chromium.org/1445003002/diff/160001/crypto/scoped_nss_type...
crypto/scoped_nss_types.h:19: typedef void AllowSelfReset;
On 2015/11/17 at 19:09:27, danakj (behind on reviews) wrote:
> Can you maybe replace each of these AllowSelfReset with a comment saying that
this destroyer was written in a way that will allow self reset?

Hmm... that's not really immediately obvious that comment would be true though
(as it depends on the actual Destroyer implementation), right? TBH, looking at
the CL that introduced this, I'm not even sure why it was needed in the end:
https://codereview.chromium.org/610533003

+davidben, is this something you'd find valuable?

https://codereview.chromium.org/1445003002/diff/160001/mojo/shell/data_pipe_p...
File mojo/shell/data_pipe_peek.cc (right):

https://codereview.chromium.org/1445003002/diff/160001/mojo/shell/data_pipe_p...
mojo/shell/data_pipe_peek.cc:8: #include <algorithm>
On 2015/11/17 at 19:09:27, danakj (behind on reviews) wrote:
> whitespace between these (cuz they are diff sets and not sorted together)

Done.

https://codereview.chromium.org/1445003002/diff/160001/ui/gfx/animation/linea...
File ui/gfx/animation/linear_animation.cc (right):

https://codereview.chromium.org/1445003002/diff/160001/ui/gfx/animation/linea...
ui/gfx/animation/linear_animation.cc:8: #include <algorithm>
On 2015/11/17 at 19:09:27, danakj (behind on reviews) wrote:
> +whitespace

Done.

[dcheng, 2015-11-17 20:27:05]

The CQ bit was checked by dcheng@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-11-17 20:27:22]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1445003002/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1445003002/180001

[davidben, 2015-11-17 21:01:45]

https://codereview.chromium.org/1445003002/diff/160001/crypto/scoped_nss_types.h
File crypto/scoped_nss_types.h (left):

https://codereview.chromium.org/1445003002/diff/160001/crypto/scoped_nss_type...
crypto/scoped_nss_types.h:19: typedef void AllowSelfReset;
On 2015/11/17 20:21:03, dcheng wrote:
> On 2015/11/17 at 19:09:27, danakj (behind on reviews) wrote:
> > Can you maybe replace each of these AllowSelfReset with a comment saying
that
> this destroyer was written in a way that will allow self reset?
> 
> Hmm... that's not really immediately obvious that comment would be true though
> (as it depends on the actual Destroyer implementation), right? TBH, looking at
> the CL that introduced this, I'm not even sure why it was needed in the end:
> https://codereview.chromium.org/610533003
> 
> +davidben, is this something you'd find valuable?

Part of this change is to remove the self-reset check in scoped_ptr altogether,
right? If so, then there's probably no need to keep a mention around as scar
tissue. So this lgtm.

(Self-reset was needed with the old scoped_ptr behavior because NSS and OpenSSL
types are all intrusively reference-counted. And so two ScopedFOO might contain
the same FOO* pointer by value, but each owns its own reference to it.)

[commit-bot: I haz the power, 2015-11-17 21:27:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-17 21:27:11]

Dry run: Try jobs failed on following builders:
  win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[brettw, 2015-11-18 00:21:52]

Can you do a pass to check for the proper spacing around the include groups? I
noted a few cases but didn't look at the whole patch. LGTM with that.

https://codereview.chromium.org/1445003002/diff/180001/base/process/process_m...
File base/process/process_metrics_win.cc (right):

https://codereview.chromium.org/1445003002/diff/180001/base/process/process_m...
base/process/process_metrics_win.cc:10: #include <algorithm>
Blank line before this.

https://codereview.chromium.org/1445003002/diff/180001/rlz/lib/rlz_lib.cc
File rlz/lib/rlz_lib.cc (right):

https://codereview.chromium.org/1445003002/diff/180001/rlz/lib/rlz_lib.cc#new...
rlz/lib/rlz_lib.cc:10: #include <algorithm>
Blank line after this.

https://codereview.chromium.org/1445003002/diff/180001/sql/mojo/vfs_unittest.cc
File sql/mojo/vfs_unittest.cc (right):

https://codereview.chromium.org/1445003002/diff/180001/sql/mojo/vfs_unittest....
sql/mojo/vfs_unittest.cc:5: #include <memory>
Blank line after this.

[dcheng, 2015-11-18 18:02:33]

On 2015/11/18 at 00:21:52, brettw wrote:
> Can you do a pass to check for the proper spacing around the include groups? I
noted a few cases but didn't look at the whole patch. LGTM with that.
> 
>
https://codereview.chromium.org/1445003002/diff/180001/base/process/process_m...
> File base/process/process_metrics_win.cc (right):
> 
>
https://codereview.chromium.org/1445003002/diff/180001/base/process/process_m...
> base/process/process_metrics_win.cc:10: #include <algorithm>
> Blank line before this.
> 
> https://codereview.chromium.org/1445003002/diff/180001/rlz/lib/rlz_lib.cc
> File rlz/lib/rlz_lib.cc (right):
> 
>
https://codereview.chromium.org/1445003002/diff/180001/rlz/lib/rlz_lib.cc#new...
> rlz/lib/rlz_lib.cc:10: #include <algorithm>
> Blank line after this.
> 
>
https://codereview.chromium.org/1445003002/diff/180001/sql/mojo/vfs_unittest.cc
> File sql/mojo/vfs_unittest.cc (right):
> 
>
https://codereview.chromium.org/1445003002/diff/180001/sql/mojo/vfs_unittest....
> sql/mojo/vfs_unittest.cc:5: #include <memory>
> Blank line after this.

Is there any actual style guide guidance around requiring newlines between C
headers, C++ headers, and everything else? The example on
https://google.github.io/styleguide/cppguide.html#Names_and_Order_of_Includes
does not include this (the system headers, both C and C++, are in one block).

[dcheng, 2015-11-18 18:03:15]

On 2015/11/18 at 18:02:33, dcheng wrote:
> On 2015/11/18 at 00:21:52, brettw wrote:
> > Can you do a pass to check for the proper spacing around the include groups?
I noted a few cases but didn't look at the whole patch. LGTM with that.
> > 
> >
https://codereview.chromium.org/1445003002/diff/180001/base/process/process_m...
> > File base/process/process_metrics_win.cc (right):
> > 
> >
https://codereview.chromium.org/1445003002/diff/180001/base/process/process_m...
> > base/process/process_metrics_win.cc:10: #include <algorithm>
> > Blank line before this.
> > 
> > https://codereview.chromium.org/1445003002/diff/180001/rlz/lib/rlz_lib.cc
> > File rlz/lib/rlz_lib.cc (right):
> > 
> >
https://codereview.chromium.org/1445003002/diff/180001/rlz/lib/rlz_lib.cc#new...
> > rlz/lib/rlz_lib.cc:10: #include <algorithm>
> > Blank line after this.
> > 
> >
https://codereview.chromium.org/1445003002/diff/180001/sql/mojo/vfs_unittest.cc
> > File sql/mojo/vfs_unittest.cc (right):
> > 
> >
https://codereview.chromium.org/1445003002/diff/180001/sql/mojo/vfs_unittest....
> > sql/mojo/vfs_unittest.cc:5: #include <memory>
> > Blank line after this.
> 
> Is there any actual style guide guidance around requiring newlines between C
headers, C++ headers, and everything else? The example on
https://google.github.io/styleguide/cppguide.html#Names_and_Order_of_Includes
does not include this (the system headers, both C and C++, are in one block).

(As in, it does not include a newline between C and C++ headers)

[dcheng, 2015-11-18 18:12:16]

(and fixed all the other ones that I found, with the exception of my question
about C/C++ system headers)

https://codereview.chromium.org/1445003002/diff/180001/rlz/lib/rlz_lib.cc
File rlz/lib/rlz_lib.cc (right):

https://codereview.chromium.org/1445003002/diff/180001/rlz/lib/rlz_lib.cc#new...
rlz/lib/rlz_lib.cc:10: #include <algorithm>
On 2015/11/18 at 00:21:52, brettw wrote:
> Blank line after this.

Done.

https://codereview.chromium.org/1445003002/diff/180001/sql/mojo/vfs_unittest.cc
File sql/mojo/vfs_unittest.cc (right):

https://codereview.chromium.org/1445003002/diff/180001/sql/mojo/vfs_unittest....
sql/mojo/vfs_unittest.cc:5: #include <memory>
On 2015/11/18 at 00:21:52, brettw wrote:
> Blank line after this.

Done.

[dcheng, 2015-11-18 18:12:21]

The CQ bit was checked by dcheng@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-11-18 18:12:49]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1445003002/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1445003002/200001

[commit-bot: I haz the power, 2015-11-18 19:27:24]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-18 19:27:25]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[dcheng, 2015-11-18 19:54:52]

The CQ bit was checked by dcheng@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-11-18 19:55:31]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1445003002/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1445003002/220001

[commit-bot: I haz the power, 2015-11-18 21:35:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-18 21:35:04]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[dcheng, 2015-11-19 02:59:32]

The CQ bit was checked by dcheng@chromium.org

[dcheng, 2015-11-19 02:59:33]

scottmg@ pointed out that it was probably precompile.h causing the build
differences. So hopefully this should work now...

[dcheng, 2015-11-19 02:59:34]

The patchset sent to the CQ was uploaded after l-g-t-m from danakj@chromium.org,
brettw@chromium.org, davidben@chromium.org
Link to the patchset: https://codereview.chromium.org/1445003002/#ps240001
(title: "Two more. Maybe it'll work this time")

[commit-bot: I haz the power, 2015-11-19 03:00:31]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1445003002/240001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1445003002/240001

[commit-bot: I haz the power, 2015-11-19 03:57:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-19 03:57:58]

Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[dcheng, 2015-11-19 05:15:54]

The CQ bit was checked by dcheng@chromium.org

[dcheng, 2015-11-19 05:15:54]

The patchset sent to the CQ was uploaded after l-g-t-m from danakj@chromium.org,
brettw@chromium.org, davidben@chromium.org
Link to the patchset: https://codereview.chromium.org/1445003002/#ps260001
(title: "How many trial and errors before this builds on the Windows bots")

[commit-bot: I haz the power, 2015-11-19 05:16:42]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1445003002/260001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1445003002/260001

[commit-bot: I haz the power, 2015-11-19 07:00:29]

Committed patchset #14 (id:260001)

[commit-bot: I haz the power, 2015-11-19 07:01:33]

Patchset 14 (id:??) landed as
https://crrev.com/0917ec4328dc20b59887d78f76b9f075e12e5f7f
Cr-Commit-Position: refs/heads/master@{#360539}