Update webkit/ to use scoped_refptr<T>::get() rather than implicit "operator T*"

Update webkit/ to use scoped_refptr<T>::get() rather than implicit "operator T*"

Linux fixes

BUG=110610
TBR=darin

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=203636

[Ryan Sleevi, 2013-06-01 01:52:31]

TBR

[commit-bot: I haz the power, 2013-06-01 01:53:10]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rsleevi@chromium.org/16155009/1

[commit-bot: I haz the power, 2013-06-02 23:47:40]

Change committed as 203636

[michaeln, 2013-06-03 22:19:30]

On 2013/06/02 23:47:40, I haz the power (commit-bot) wrote:
> Change committed as 203636

Hi ryan,

We're in the middle of moving all of the source files in /webkit to new
locations. If you have any other cleanup tasks like this one in /webkit, please
hold off until that migration is done. Also, while the changes are purely
mechanical, getting a review from somebody that works in this neck of the woods
would be helpful all the same to prevent conflicts and such.

We have to replicate your changes in a bunch of files we have in flight (roughly
half by eyeballing it).

@kinuko, fyi appcache files your deleting/moving have changed underneath you.

[Ryan Sleevi, 2013-06-03 22:39:06]

On 2013/06/03 22:19:30, michaeln wrote:
> On 2013/06/02 23:47:40, I haz the power (commit-bot) wrote:
> > Change committed as 203636
> 
> Hi ryan,
> 
> We're in the middle of moving all of the source files in /webkit to new
> locations. If you have any other cleanup tasks like this one in /webkit,
please
> hold off until that migration is done. Also, while the changes are purely
> mechanical, getting a review from somebody that works in this neck of the
woods
> would be helpful all the same to prevent conflicts and such.
> 
> We have to replicate your changes in a bunch of files we have in flight
(roughly
> half by eyeballing it).
> 
> @kinuko, fyi appcache files your deleting/moving have changed underneath you.

Hey Michael,

Thanks for the heads up. I spoke with Darin beforehand to make sure this was
going to be kosher to TBR. This was also extensively discussed on chromium-dev
(it just took 6 months from when Will proposed it).

You should find with Git these changes to be extremely trivial and auto-merge.

There are still several phases of cleanup (this is part of Phase 1), and several
others are eager to see the remaining phases completed. I'd like to see if we
can't find a solution that's going to avoid blocking this work - having cleanup
tasks like this blocked is not ideal at all.

Do you have an ETA on when the migration will be completed? Hours? Days? Weeks?
Longer?

[jamesr, 2013-06-03 22:40:38]

On 2013/06/03 22:39:06, Ryan Sleevi wrote:
> On 2013/06/03 22:19:30, michaeln wrote:
> > On 2013/06/02 23:47:40, I haz the power (commit-bot) wrote:
> > > Change committed as 203636
> > 
> > Hi ryan,
> > 
> > We're in the middle of moving all of the source files in /webkit to new
> > locations. If you have any other cleanup tasks like this one in /webkit,
> please
> > hold off until that migration is done. Also, while the changes are purely
> > mechanical, getting a review from somebody that works in this neck of the
> woods
> > would be helpful all the same to prevent conflicts and such.
> > 
> > We have to replicate your changes in a bunch of files we have in flight
> (roughly
> > half by eyeballing it).
> > 
> > @kinuko, fyi appcache files your deleting/moving have changed underneath
you.
> 
> Hey Michael,
> 
> Thanks for the heads up. I spoke with Darin beforehand to make sure this was
> going to be kosher to TBR. This was also extensively discussed on chromium-dev
> (it just took 6 months from when Will proposed it).
> 
> You should find with Git these changes to be extremely trivial and auto-merge.
> 
> There are still several phases of cleanup (this is part of Phase 1), and
several
> others are eager to see the remaining phases completed. I'd like to see if we
> can't find a solution that's going to avoid blocking this work - having
cleanup
> tasks like this blocked is not ideal at all.
> 
> Do you have an ETA on when the migration will be completed? Hours? Days?
Weeks?
> Longer?

Go ahead, it's really easy to merge changes like this.  We'll be continuing the
migration for the next few weeks most likely.

[michaeln, 2013-06-03 22:58:18]

> Go ahead, it's really easy to merge changes like this.  We'll be continuing
the
> migration for the next few weeks most likely.

Let me be more constrained in my request, please hold off on search-n-destroy
cleanup changes in webkit/appcache and webkit/dom_storage. I'm still using svn
and svn does not automerge changes like this to moved/deleted files.

> Thanks for the heads up. I spoke with Darin beforehand to make sure this was
> going to be kosher to TBR. This was also extensively discussed on chromium-dev
> (it just took 6 months from when Will proposed it).

The changes are fine and good (i definitely prefer the explicit .get).

[Ryan Sleevi, 2013-06-03 23:33:51]

On 2013/06/03 22:58:18, michaeln wrote:
> > Go ahead, it's really easy to merge changes like this.  We'll be continuing
> the
> > migration for the next few weeks most likely.
> 
> Let me be more constrained in my request, please hold off on search-n-destroy
> cleanup changes in webkit/appcache and webkit/dom_storage. I'm still using svn
> and svn does not automerge changes like this to moved/deleted files.

Can you give an ETA on this? I had hoped to complete the refactoring within the
next few days.

Fred Akalin is in the process of a similar change for WeakPtr<>, so I expect
he's going to run into the same concerns you're at here.

I'm certainly not trying to stomp on any toes, but I do want to make sure we
have a clear migration path and aren't leaving things midstream. Ultimately,
this was done with automated tooling, so it's possible to re-do if necessary - I
would just like to finish this sooner than later so that we can actually close
out the pattern in the code and avoid the continual firefighting of new usages
constantly being introduced across the codebase.

> 
> > Thanks for the heads up. I spoke with Darin beforehand to make sure this was
> > going to be kosher to TBR. This was also extensively discussed on
chromium-dev
> > (it just took 6 months from when Will proposed it).
> 
> The changes are fine and good (i definitely prefer the explicit .get).

[michaeln1, 2013-06-04 00:11:39]

I expect to land dom_storage moving today, I'm retrying after merging in
your changes.  Kinuko has a patch up for appcache that;s not yet complete
but is close (but she's using git so it may not matter for her).


On Mon, Jun 3, 2013 at 4:33 PM, <rsleevi@chromium.org> wrote:

> On 2013/06/03 22:58:18, michaeln wrote:
>
>> > Go ahead, it's really easy to merge changes like this.  We'll be
>> continuing
>> the
>> > migration for the next few weeks most likely.
>>
>
>  Let me be more constrained in my request, please hold off on
>> search-n-destroy
>> cleanup changes in webkit/appcache and webkit/dom_storage. I'm still
>> using svn
>> and svn does not automerge changes like this to moved/deleted files.
>>
>
> Can you give an ETA on this? I had hoped to complete the refactoring
> within the
> next few days.
>
> Fred Akalin is in the process of a similar change for WeakPtr<>, so I
> expect
> he's going to run into the same concerns you're at here.
>
> I'm certainly not trying to stomp on any toes, but I do want to make sure
> we
> have a clear migration path and aren't leaving things midstream.
> Ultimately,
> this was done with automated tooling, so it's possible to re-do if
> necessary - I
> would just like to finish this sooner than later so that we can actually
> close
> out the pattern in the code and avoid the continual firefighting of new
> usages
> constantly being introduced across the codebase.
>
>
>
>  > Thanks for the heads up. I spoke with Darin beforehand to make sure
>> this was
>> > going to be kosher to TBR. This was also extensively discussed on
>>
> chromium-dev
>
>> > (it just took 6 months from when Will proposed it).
>>
>
>  The changes are fine and good (i definitely prefer the explicit .get).
>>
>
>
>
>
https://chromiumcodereview.**appspot.com/16155009/<https://chromiumcodereview...
>