Made Frame constructors (and subclasses) take Page& instead of Page*

Made Frame constructors (and subclasses) take Page& instead of Page*

Made Frame constructors (and subclasses LocalFrame and RemoteFrame) take
Page& instead of Page*, since this parameter can't be null.

BUG=688614
Review-Url: https://codereview.chromium.org/2762423003
Cr-Commit-Position: refs/heads/master@{#459985}
Committed: https://chromium.googlesource.com/chromium/src/+/2b6e31dfcf2062a3dec7942daf86dc79864c14e8

[sashab, 2017-03-22 02:03:27]

sashab@chromium.org changed reviewers:
+ slangley@chromium.org

[haraken, 2017-03-22 02:34:11]

LGTM

[sashab, 2017-03-22 02:35:35]

The CQ bit was checked by sashab@chromium.org

[commit-bot: I haz the power, 2017-03-22 02:36:24]

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

[commit-bot: I haz the power, 2017-03-22 02:36:26]

This CL has an open dependency (Issue 2764773003 Patch 20001). Please resolve
the dependency and try again.
If you are sure that there is no real dependency, please use one of the options
listed in https://goo.gl/9Es4OR to land the CL.

[slangley, 2017-03-22 03:01:59]

slangley@chromium.org changed reviewers:
+ haraken@chromium.org

[slangley, 2017-03-22 03:02:00]

According to the style guide if there is no transfer of ownership you should use
pointer parameters.

https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md...

That would imply that the right thing to do here is to CHECK() you didn't get
nullptr rather than taking a ref.

[sashab, 2017-03-22 03:11:33]

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

[sashab, 2017-03-22 03:11:34]

dcheng@ ptal at slangley@s comment

[haraken, 2017-03-22 03:33:43]

On 2017/03/22 03:11:34, sashab wrote:
> dcheng@ ptal at slangley@s comment

I don't have any strong opinion. Blink has historically preferred using a
reference over a pointer for things that shouldn't be null.

c.f., Very long discussion:
https://groups.google.com/a/chromium.org/d/topic/blink-dev/YrWxDDGyDMc/discus...

[dcheng, 2017-03-22 03:48:10]

On 2017/03/22 03:33:43, haraken wrote:
> On 2017/03/22 03:11:34, sashab wrote:
> > dcheng@ ptal at slangley@s comment
> 
> I don't have any strong opinion. Blink has historically preferred using a
> reference over a pointer for things that shouldn't be null.
> 
> c.f., Very long discussion:
>
https://groups.google.com/a/chromium.org/d/topic/blink-dev/YrWxDDGyDMc/discus...

We inherited this convention from WebKit, and we've explicitly opted to retain
it, even though we're working on converging the rest of Blink style with
Chromium: see
https://docs.google.com/document/d/1ZQLiQKw9hCOyDDhDS4JhckhuiJmLqSbw9FLfySMyx....

[slangley, 2017-03-22 05:36:22]

On 2017/03/22 at 03:48:10, dcheng wrote:
> On 2017/03/22 03:33:43, haraken wrote:
> > On 2017/03/22 03:11:34, sashab wrote:
> > > dcheng@ ptal at slangley@s comment
> > 
> > I don't have any strong opinion. Blink has historically preferred using a
> > reference over a pointer for things that shouldn't be null.
> > 
> > c.f., Very long discussion:
> >
https://groups.google.com/a/chromium.org/d/topic/blink-dev/YrWxDDGyDMc/discus...
> 
> We inherited this convention from WebKit, and we've explicitly opted to retain
it, even though we're working on converging the rest of Blink style with
Chromium: see
https://docs.google.com/document/d/1ZQLiQKw9hCOyDDhDS4JhckhuiJmLqSbw9FLfySMyx....

Daniel - do you mean we should try and use pointers in an attempt to converge
with chromium in new code, or we always plan on using & for non-null (and
diverging from chromium style on this point) and should continue to do so in new
code?

[dcheng, 2017-03-22 05:42:03]

On 2017/03/22 05:36:22, slangley wrote:
> On 2017/03/22 at 03:48:10, dcheng wrote:
> > On 2017/03/22 03:33:43, haraken wrote:
> > > On 2017/03/22 03:11:34, sashab wrote:
> > > > dcheng@ ptal at slangley@s comment
> > > 
> > > I don't have any strong opinion. Blink has historically preferred using a
> > > reference over a pointer for things that shouldn't be null.
> > > 
> > > c.f., Very long discussion:
> > >
>
https://groups.google.com/a/chromium.org/d/topic/blink-dev/YrWxDDGyDMc/discus...
> > 
> > We inherited this convention from WebKit, and we've explicitly opted to
retain
> it, even though we're working on converging the rest of Blink style with
> Chromium: see
>
https://docs.google.com/document/d/1ZQLiQKw9hCOyDDhDS4JhckhuiJmLqSbw9FLfySMyx....
> 
> Daniel - do you mean we should try and use pointers in an attempt to converge
> with chromium in new code, or we always plan on using & for non-null (and
> diverging from chromium style on this point) and should continue to do so in
new
> code?

To clarify: we should use & for non-null, even though it diverges from Chromium
style, and continue to do so in new code.

[sashab, 2017-03-22 05:51:05]

The CQ bit was checked by sashab@chromium.org

[sashab, 2017-03-22 05:51:10]

The CQ bit was unchecked by sashab@chromium.org

[sashab, 2017-03-23 23:40:32]

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

[commit-bot: I haz the power, 2017-03-23 23:40:59]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-24 02:17:30]

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

[commit-bot: I haz the power, 2017-03-24 02:17:31]

Dry run: This issue passed the CQ dry run.

[sashab, 2017-03-28 00:30:46]

The CQ bit was checked by sashab@chromium.org

[sashab, 2017-03-28 00:30:47]

The patchset sent to the CQ was uploaded after l-g-t-m from haraken@chromium.org
Link to the patchset: https://codereview.chromium.org/2762423003/#ps20001
(title: "Rebase")

[commit-bot: I haz the power, 2017-03-28 00:31:06]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-28 02:10:59]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1490661046543990,
"parent_rev": "31d55d991baf03aa9bc3ff5d5e67f709eee77959", "commit_rev":
"2b6e31dfcf2062a3dec7942daf86dc79864c14e8"}

[commit-bot: I haz the power, 2017-03-28 02:11:41]

Description was changed from

==========
Made Frame constructors (and subclasses) take Page& instead of Page*

Made Frame constructors (and subclasses LocalFrame and RemoteFrame) take
Page& instead of Page*, since this parameter can't be null.

BUG=688614
==========

to

==========
Made Frame constructors (and subclasses) take Page& instead of Page*

Made Frame constructors (and subclasses LocalFrame and RemoteFrame) take
Page& instead of Page*, since this parameter can't be null.

BUG=688614

Review-Url: https://codereview.chromium.org/2762423003
Cr-Commit-Position: refs/heads/master@{#459985}
Committed:
https://chromium.googlesource.com/chromium/src/+/2b6e31dfcf2062a3dec7942daf86...
==========

[commit-bot: I haz the power, 2017-03-28 02:11:42]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/2b6e31dfcf2062a3dec7942daf86...