Add tests for detached buffer validation on TypedArray methods

[leobalter]

these tests requires an extra implementation on the runners. Ref harness/detachArrayBuffer.js

[leobalter]

I rearranged the commits to isolate the harness/detachArrayBuffer.js file in a single commit.

There are also rebased with the last changes on master.

[jugglinmike]

This invocation needs to specify a valid buffer size.

[leobalter]

I almost got it valid! tc39/ecma262#410 :)

maybe in a near future, but I'll fix this for now.

[jugglinmike]

We want something defined at harness/detachArrayBuffer.js by default--that
gives us an opportunity to communicate the requirement more clearly
(implementers will see your error message, not an OS-level warning about
non-existent files). Instead of testing for ArrayBuffer.transfer, though, we
should use some future-proof reference--maybe Test262DetachArrayBuffer. It's
doesn't really matter what we choose; any reference that is unlikely to be
standardized will do. In addition, an in-line comment that documents the
expected behavior of the function will be helpful.

Speaking of which, I think the usage of the helper is incorrect here. Every
invocation specifies a TypedArray as the first argument, but the name of the
helper (and the implementation provided) strongly suggest that it should be
invoked with an ArrayBuffer instance.

Up until now, we've been using the built-ins/TypedArray directory for tests
that do not use any particular TypedArray subclass. The tests that assert the
behavior of all the subclasses together (using
testWithTypedArrayConstructors) are generally located in
built-ins/TypedArrays. The placement of these new files contradicts that
pattern, though. Is there a specific reason to do this?

[jugglinmike]

Also, it might be a good idea to create a new buffer for each iteration. Implementations might define guards against detaching an already-detached buffer (es6draft does this). It's tricky because we can't account for all behaviors of a non-standard function, but it seems like this is a likely error we could avoid easily.

[leobalter]

f483954

[leobalter]

we should use some future-proof reference--maybe Test262DetachArrayBuffer

Isn't the $DETACHBUFFER enough for this reference? I could remove the calls for ArrayBuffer.transfer inside, but we don't need to use another reference inside.

Speaking of which, I think the usage of the helper is incorrect here. Every
invocation specifies a TypedArray as the first argument, but the name of the
helper (and the implementation provided) strongly suggest that it should be
invoked with an ArrayBuffer instance.

sure thing

The placement of these new files contradicts that pattern, though. Is there a specific reason to do this?

The tests we have on built-ins/TypedArrays/prototype/* are checking only they inherit from TypedArray.prototype. All the other tests are currently being addressed to built-ins/TypedArray/prototype as I'm testing the methods, regardless of the constructor, but I'm indeed using samples of each constructor designed to be used with them.

[jugglinmike]

Isn't the $DETACHBUFFER enough for this reference? I could remote the calls for ArrayBuffer.transfer inside, but we don't need to use another reference inside.

Actually, yes. I was over-thinking the amount of indirection we'd need. Let's
remove ArrayBuffer.transfer, though, and throw in all cases (despite being a
likely solution, ArrayBuffer.transfer may still change in ways that invalidate
our usage here).

I'm indeed using samples of each constructor designed to be used with them.

Sounds good to me

[leobalter]

Let's remove ArrayBuffer.transfer, though, and throw in all cases

Doing it. It's funny how this is a 100% guaranteed way to land valid but failing tests.

---

fixing a typo from a past comment as it bugs me: I could remove the calls for ArrayBuffer.transfer (s/remote/remove)

[leobalter]

done. 5441ac3

[jugglinmike]

This is a good idea, but it doesn't serve the intended purpose. The spec calls ToString, so the method to define here is toString.

[leobalter]

inline comments fixed at d806df0

[jugglinmike]

Merged to master at commits 70c7375 and ce503e6. Thanks!