[api] expose Array Iterators to API

[api] expose Array Iterators to API

Allow access to Array Iterator through the API, in order to simplify
setting up interfaces which use these methods. This applies to
WebIDL interfaces with "length" attributes returning integer types and
a getter taking an unsigned long type.

BUG=
LOG=N
R=adamk@chromium.org

Committed: https://crrev.com/24aca8709000f1d05341aaa7f131369896f72b63
Cr-Commit-Position: refs/heads/master@{#31152}

[caitp (gmail), 2015-10-04 19:29:17]

Hi,

I wanted to expose these through the API in order to simplify using these in
Blink bindings, since I've got a little side project of getting more of the
iterable DOM interfaces working correctly.

Downsides of CL:
  - Adds another 3 pointers to the native context, growing the size a bit.

Updates:
  - Simpler access to these methods, and more of a guarantee that they are what
they should be

---

For my own purposes on the Blink side, I don't really need the keys or entries
iterators, so just exposing ArrayValues to the API would be good enough. entries
and values will still likely be useful later on, for integer-indexed types.

[caitp (gmail), 2015-10-05 12:16:23]

On 2015/10/04 19:29:17, caitp wrote:
> Hi,
> 
> I wanted to expose these through the API in order to simplify using these in
> Blink bindings, since I've got a little side project of getting more of the
> iterable DOM interfaces working correctly.
> 
> Downsides of CL:
>   - Adds another 3 pointers to the native context, growing the size a bit.
> 
> Updates:
>   - Simpler access to these methods, and more of a guarantee that they are
what
> they should be
> 
> ---
> 
> For my own purposes on the Blink side, I don't really need the keys or entries
> iterators, so just exposing ArrayValues to the API would be good enough.
entries
> and values will still likely be useful later on, for integer-indexed types.

I'm using this in https://codereview.chromium.org/1381413003/ (partly, without
the Keys/Entries iterators)

It might be better to provide an alternative way for the API to construct Array
Iterators, though? Other than the "
If the interface does not have an iterable declaration but does define an
indexed property getter, then the Function object is %ArrayProto_values%
([ECMA-262], section 6.1.7.4)." clause, there doesn't seem to be any requirement
that the same intrinsic functions are used for constructing the iterators

[adamk, 2015-10-05 20:28:16]

adamk@chromium.org changed reviewers:
+ jochen@chromium.org

[adamk, 2015-10-05 20:28:16]

I don't have OWNERS for the API, adding Jochen.

Given the specification about %ArrayProto_values%, it seems pretty clear that
you need to, at least, expose v8::Array::GetValuesIterator. I'll leave it up to
Jochen whether we should eagerly add more iterator-getters or do them as needed
on the Blink side.

[caitp (gmail), 2015-10-05 22:16:57]

On 2015/10/05 20:28:16, adamk wrote:
> I don't have OWNERS for the API, adding Jochen.
> 
> Given the specification about %ArrayProto_values%, it seems pretty clear that
> you need to, at least, expose v8::Array::GetValuesIterator. I'll leave it up
to
> Jochen whether we should eagerly add more iterator-getters or do them as
needed
> on the Blink side.

Sorry, i probably need to read the OWNERS files instead of depending on
presubmit warnings that aren't happening

[adamk, 2015-10-05 22:19:14]

On 2015/10/05 22:16:57, caitp wrote:
> On 2015/10/05 20:28:16, adamk wrote:
> > I don't have OWNERS for the API, adding Jochen.
> > 
> > Given the specification about %ArrayProto_values%, it seems pretty clear
that
> > you need to, at least, expose v8::Array::GetValuesIterator. I'll leave it up
> to
> > Jochen whether we should eagerly add more iterator-getters or do them as
> needed
> > on the Blink side.
> 
> Sorry, i probably need to read the OWNERS files instead of depending on
> presubmit warnings that aren't happening

I think the presubmit is actually technically correct here, since include/OWNERS
doesn't have a set noparent in it. But I defer to jochen nevertheless for actual
API changes.

[jochen (gone - plz use gerrit), 2015-10-07 09:27:03]

lgtm

[caitp (gmail), 2015-10-07 10:51:41]

On 2015/10/07 09:27:03, jochen wrote:
> lgtm

Thanks --- If it ends up being too much stuff added to the context, I'll prepare
a followup

[caitp (gmail), 2015-10-07 12:11:51]

The CQ bit was checked by caitpotter88@gmail.com

[commit-bot: I haz the power, 2015-10-07 12:12:04]

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

[commit-bot: I haz the power, 2015-10-07 12:12:56]

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

[commit-bot: I haz the power, 2015-10-07 12:12:56]

Try jobs failed on following builders:
  v8_linux64_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel/builds/10387)
  v8_linux_arm_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel/builds/8734)
  v8_linux_mips64el_compile_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_mips64el_compile_r...)
  v8_linux_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_rel/builds/10302)
  v8_mac_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_mac_rel/builds/10441)
  v8_presubmit on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/6441)

[caitp (gmail), 2015-10-07 12:44:26]

On 2015/10/07 12:12:56, commit-bot: I haz the power wrote:
> Try jobs failed on following builders:
>   v8_linux64_rel on tryserver.v8 (JOB_FAILED,
> http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel/builds/10387)
>   v8_linux_arm_rel on tryserver.v8 (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel/builds/8734)
>   v8_linux_mips64el_compile_rel on tryserver.v8 (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_mips64el_compile_r...)
>   v8_linux_rel on tryserver.v8 (JOB_FAILED,
> http://build.chromium.org/p/tryserver.v8/builders/v8_linux_rel/builds/10302)
>   v8_mac_rel on tryserver.v8 (JOB_FAILED,
> http://build.chromium.org/p/tryserver.v8/builders/v8_mac_rel/builds/10441)
>   v8_presubmit on tryserver.v8 (JOB_FAILED,
> http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/6441)

wat!

[caitp (gmail), 2015-10-07 12:53:27]

The CQ bit was checked by caitpotter88@gmail.com

[caitp (gmail), 2015-10-07 12:53:27]

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

[commit-bot: I haz the power, 2015-10-07 12:53:32]

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

[commit-bot: I haz the power, 2015-10-07 13:17:10]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-10-07 13:17:24]

Patchset 2 (id:??) landed as
https://crrev.com/24aca8709000f1d05341aaa7f131369896f72b63
Cr-Commit-Position: refs/heads/master@{#31152}