Use "= delete" for DISALLOW_COPY and DISALLOW_ASSIGN.

Use "= delete" for DISALLOW_COPY and DISALLOW_ASSIGN.

This will guarantee the error to be at compile time, and not rely on
the call visibility (private).

DISALLOW_COPY_AND_ASSIGN and DISSALOW_IMPLICIT_CONSTRUCTORS can't be
changed yet because they are redefine in different place in the code
base.

BUG=447156
Committed: https://crrev.com/a99741d56bdc73608504be57832100652f9e4cd0
Cr-Commit-Position: refs/heads/master@{#331017}

[mlamouri (slow - plz ping), 2015-05-20 10:48:29]

mlamouri@chromium.org changed reviewers:
+ thakis@chromium.org

[Nico, 2015-05-20 15:32:04]

This is roughly crbug.com/447156

The commit message is incorrect: These macros are supposed to be in a private:
section, and in that case they already fire at compile time.

Generally I think this is a good idea, but it might be confusing if
DISALLOW_COPY_AND_ASSIGN and these two behave differently – I kind of feel we
might want to change all three of them at the same time?

[mlamouri (slow - plz ping), 2015-05-20 15:40:12]

On 2015/05/20 at 15:32:04, thakis wrote:
> This is roughly crbug.com/447156
> 
> The commit message is incorrect: These macros are supposed to be in a private:
section, and in that case they already fire at compile time.

Sure but you sometimes might trigger the disallowed methods from code allowed to
access it. Also, it's easy to forget to add private: for struct (I wrote that CL
because exactly that happened to me).

> Generally I think this is a good idea, but it might be confusing if
DISALLOW_COPY_AND_ASSIGN and these two behave differently – I kind of feel we
might want to change all three of them at the same time?

Why would that be confusing? I don't expect people to start changing their
habits TBH. Otherwise, there are two other macros that need to be changed. My
plan is to fix the breakage (one was because of Blink IIRC, the other because of
a third party library). There might be more.

I would prefer to work on this incrementally but it's ultimately your decision.

[Nico, 2015-05-21 03:11:43]

On 2015/05/20 15:40:12, Mounir Lamouri wrote:
> On 2015/05/20 at 15:32:04, thakis wrote:
> > This is roughly crbug.com/447156
> > 
> > The commit message is incorrect: These macros are supposed to be in a
private:
> section, and in that case they already fire at compile time.
> 
> Sure but you sometimes might trigger the disallowed methods from code allowed
to
> access it. Also, it's easy to forget to add private: for struct (I wrote that
CL
> because exactly that happened to me).
> 
> > Generally I think this is a good idea, but it might be confusing if
> DISALLOW_COPY_AND_ASSIGN and these two behave differently – I kind of
feel we
> might want to change all three of them at the same time?
> 
> Why would that be confusing?

You say that you sometimes forget to put these macros into a private: section.
Before this CL, it wouldn't do what you'd expect, and you'd think "oh right I
forgot private". After this CL, it'll work for some macros, and if you forget
private for a macro that is not deleted yet you'd probably wonder why it doesn't
work for those but works for the others.

> I would prefer to work on this incrementally but it's ultimately your
decision.

These two macros don't need seem to need a lot of churn, so this CL should be
easy to land when the main one is converted.

But I don't think it makes a huge difference either way. If it's useful to you
to land this earlier, then go ahead, lgtm (with the "compile time instead of
link time" paragraph removed from the CL description as it's not really
correct).

[Nico, 2015-05-21 03:12:00]

(also, sorry about the huge delay, I didn't have a computer near me today)

[mlamouri (slow - plz ping), 2015-05-21 15:32:35]

The CQ bit was checked by mlamouri@chromium.org

[commit-bot: I haz the power, 2015-05-21 15:32:53]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1151443003/1

[commit-bot: I haz the power, 2015-05-21 22:54:14]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-05-21 22:56:07]

Patchset 1 (id:??) landed as
https://crrev.com/a99741d56bdc73608504be57832100652f9e4cd0
Cr-Commit-Position: refs/heads/master@{#331017}