Updated fast/canvas/webgl-array-invalid-ranges.html

Updated fast/canvas/webgl-array-invalid-ranges.html

This test still assumes that the following command should throw an exception:
var array = new TypedArray(null, 0, 0);

The specs https://www.khronos.org/registry/typedarray/specs/latest/#TYPEDARRAYS
doesn't say it should throw an exception. So we update this test.

BUG=623120
Committed: https://crrev.com/60236bcc191a774f0a1cb243b2dc8b3edfc122e9
Cr-Commit-Position: refs/heads/master@{#426533}

[xidachen, 2016-10-20 15:15:08]

xidachen@chromium.org changed reviewers:
+ jbroman@chromium.org

[xidachen, 2016-10-20 15:15:08]

PTAL

[jbroman, 2016-10-20 15:24:04]

jbroman@chromium.org changed reviewers:
+ kbr@chromium.org

[jbroman, 2016-10-20 15:24:04]

+kbr, who's an editor of the spec in question

Hmm, my understanding of the IDL is that the ArrayBuffer parameter is _not_
nullable (it doesn't have a ? at the end).

And the WebIDL spec says that null is not implicitly included in the set of
values of the IDL ArrayBuffer type:
https://heycam.github.io/webidl/#idl-buffer-source-types

This is consistent with what Firefox nightly does. Are you sure this isn't a
real bug (possibly in V8)?

[jbroman, 2016-10-20 15:58:09]

On a closer look, the draft ES spec seems to handle this under the
TypedArray(length) overload, of all things:
https://tc39.github.io/ecma262/#sec-typedarray-length

By my reading, that's the overload that matches this case (since Type(null) is
not Object). Thus it gets coerced to an index (0), and all following parameters
are ignored, so the call is treated like "new type(0)".

I'd still like kbr to weigh in before landing this, though.

[Ken Russell (switch to Gerrit), 2016-10-20 17:02:55]

On 2016/10/20 15:58:09, jbroman wrote:
> On a closer look, the draft ES spec seems to handle this under the
> TypedArray(length) overload, of all things:
> https://tc39.github.io/ecma262/#sec-typedarray-length
> 
> By my reading, that's the overload that matches this case (since Type(null) is
> not Object). Thus it gets coerced to an index (0), and all following
parameters
> are ignored, so the call is treated like "new type(0)".
> 
> I'd still like kbr to weigh in before landing this, though.

I'm not 100% sure how to read the ECMAScript spec in this area -- I find it
confusing -- but this definitely works now.

The Khronos specs are obsolete now that typed arrays have been subsumed into
ECMAScript. I've just committed a change to these specifications linking to the
ECMAScript spec, which should show up within an hour or so.

Also: the typed array tests which are part of the WebGL conformance suite have
already been updated for the new behavior. You can refer to those for the
current expected results. You could also feel free to delete layout tests which
are now duplicated. These tests originally came from WebKit and we don't need
all of them any more.

LGTM

[xidachen, 2016-10-20 17:06:12]

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

[xidachen, 2016-10-20 17:06:52]

On 2016/10/20 17:02:55, Ken Russell wrote:
> On 2016/10/20 15:58:09, jbroman wrote:
> > On a closer look, the draft ES spec seems to handle this under the
> > TypedArray(length) overload, of all things:
> > https://tc39.github.io/ecma262/#sec-typedarray-length
> > 
> > By my reading, that's the overload that matches this case (since Type(null)
is
> > not Object). Thus it gets coerced to an index (0), and all following
> parameters
> > are ignored, so the call is treated like "new type(0)".
> > 
> > I'd still like kbr to weigh in before landing this, though.
> 
> I'm not 100% sure how to read the ECMAScript spec in this area -- I find it
> confusing -- but this definitely works now.
> 
> The Khronos specs are obsolete now that typed arrays have been subsumed into
> ECMAScript. I've just committed a change to these specifications linking to
the
> ECMAScript spec, which should show up within an hour or so.
> 
> Also: the typed array tests which are part of the WebGL conformance suite have
> already been updated for the new behavior. You can refer to those for the
> current expected results. You could also feel free to delete layout tests
which
> are now duplicated. These tests originally came from WebKit and we don't need
> all of them any more.
> 
> LGTM

Thanks Ken. I will do a round of clean up later based on the current WebGL
conformance test suite.

[commit-bot: I haz the power, 2016-10-20 17:07:01]

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

[xidachen, 2016-10-20 17:58:10]

The CQ bit was unchecked by xidachen@chromium.org

[xidachen, 2016-10-20 17:58:26]

The CQ bit was checked by xidachen@chromium.org

[commit-bot: I haz the power, 2016-10-20 17:59:10]

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, 2016-10-20 18:17:17]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-10-21 13:20:19]

Description was changed from

==========
Updated fast/canvas/webgl-array-invalid-ranges.html

This test still assumes that the following command should throw an exception:
var array = new TypedArray(null, 0, 0);

The specs https://www.khronos.org/registry/typedarray/specs/latest/#TYPEDARRAYS
doesn't say it should throw an exception. So we update this test.

BUG=623120
==========

to

==========
Updated fast/canvas/webgl-array-invalid-ranges.html

This test still assumes that the following command should throw an exception:
var array = new TypedArray(null, 0, 0);

The specs https://www.khronos.org/registry/typedarray/specs/latest/#TYPEDARRAYS
doesn't say it should throw an exception. So we update this test.

BUG=623120

Committed: https://crrev.com/60236bcc191a774f0a1cb243b2dc8b3edfc122e9
Cr-Commit-Position: refs/heads/master@{#426533}
==========

[commit-bot: I haz the power, 2016-10-21 13:20:20]

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