Normative: remove Symbol.species from InitializeTypedArrayFromTypedArray

[syg]

Closes #2677

[syg]

Test262 PR: tc39/test262#3460

[anba]

CloneArrayBuffer is now always called with %ArrayBuffer%, so we can also:

1. Remove the cloneConstructor argument from CloneArrayBuffer.
2. Change the IsDetachedBuffer check in CloneArrayBuffer to an assertion.

Furthermore I think we should move this line in InitializeTypedArrayFromTypedArray:

If srcArray.[[ContentType]] ≠ O.[[ContentType]], throw a TypeError exception.

So that it appears before the AllocateArrayBuffer call (or possibly even before the outer if-else block). That way an incompatible typed array type always throws a TypeError. Currently a TypeError or RangeError can be thrown, as seen below. (Technically speaking, for implementations it should already be possible to perform the typed array type check before the allocation, because the RangeError clause in CreateByteDataBlock is loose enough, so that it's not required to throw a RangeError if the returned Data Block isn't used. Kind of: "If a tree falls in a forest and no one is around to hear it, does it make a sound?")

SpiderMonkey and V8 show this behaviour:

js> void new BigInt64Array(new Int8Array(4*1024*1024*1024))  
typein:1:6 RangeError: invalid array length
Stack:
  @typein:1:6
js> void new BigInt64Array(new Int8Array(1*1024*1024*1024)) 
typein:2:6 TypeError: Int8Array elements are incompatible with BigInt64Array
Stack:
  @typein:2:6

[syg]

Thanks for the suggestions, @anba. 1 and 2 are definitely in scope for this PR and I'll make the changes.

The suggestion for moving If srcArray.[[ContentType]] ≠ O.[[ContentType]], throw a TypeError exception. seems better as a separate follow up issue, mind filing it separately?

[bakkot]

LGTM other than comments.