Array.prototype.slice should only normalize result if it's an array

test/mjsunit/regress/regress-crbug-618788.js

Index: test/mjsunit/regress/regress-crbug-618788.js
diff --git a/test/intl/regexp-prepare.js b/test/mjsunit/regress/regress-crbug-618788.js
similarity index 51%
copy from test/intl/regexp-prepare.js
copy to test/mjsunit/regress/regress-crbug-618788.js
index dec84110ed02e30bba674538534a069f7d43d39d..6e49ec2f503762b7fc5f969caf46edb510f970d8 100644
--- a/test/intl/regexp-prepare.js
+++ b/test/mjsunit/regress/regress-crbug-618788.js
@@ -2,4 +2,7 @@
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
-/(\w)(\w)(\w)(\w)(\w)(\w)(\w)(\w)(\w)(\w)/.exec(">>>abcdefghij<<<");
+var a = new Array();
+a.constructor = Int32Array;
+a.length = 1000; // Make the length >= 1000 so UseSparseVariant returns true.
+assertThrows(() => a.slice());

[Camillo Bruni, 2016/06/10 14:04:25]

Can you convince me that we have to throw here?
Normalization is certainly wrong, but slice should just work on any array-like
receiver, right?

[adamk, 2016/06/10 16:33:17]

Oh, this is throwing for perfectly "good" reasons (slice fails to set 'length'
on the Int32Array it creates). Would a comment suffice?

[Camillo Bruni, 2016/06/12 12:35:45]

humm, the above code works in FF though (yes my ultimate standard).
Shouldn't then Array.prototype.slice.call(new Int32Array(10)) fail as well (that
currently works just fine)?

[adamk, 2016/06/13 12:16:21]

From offline discussion: I don't know why Firefox works, but it shouldn't: the
last step of slice is to attempt to set the value of the 'length' property, and
this will throw for TypedArrays (since they have a getter but no setter).

As for the .call() version, that hits the !isArray case of ArraySpeciesCreate,
and so a normal array is returned. The special thing about this test case is
that it passes isArray, but because we've messed with its 'constructor'
property, which causes slice to construct the TypedArray instead of an Array.