TypedArraySpeciesCreate, step 6 isn't currently implemented:

6. If result.[[ContentType]] is not equal to exemplar.[[ContentType]], throw a TypeError exception.

Example:

var ta = new Float64Array(0);
ta.constructor = BigInt64Array;
var result = ta.slice(0);

Expected: Throws TypeError.
Actual: No error thrown.

The closest intrinsic to validate the type is GetTypedArrayKind, but that one isn't currently inlinable, which means there'll be a performance cost using it for TypedArraySpeciesCreate.

Add PossiblyWrappedTypedArrayIsBigInt to check if a TypedArray uses BigInt elements:

• Testing for BigInt TypedArrays matches what we do in C++ code.
• Uses UnwrapAndDowncastValue instead of maybeUnwrapAs, because dead object
  wrappers are possible for this case.
• Has basic inlining support to avoid regressing the TypedArray built-ins like
  slice, which were previously optimised to use fully inlinable TypedArray
  allocation.

Drive-by change:

• Update TypedArrayFill to use the new inlinable helper function.

The severity field is not set for this bug.
:jorendorff, could you have a look please?

For more information, please visit auto_nag documentation.

The proposal to dismantle @@species would indeed remove this whole function.

It'll probably go forward, but it'll be a while. :-\