SIMD.XXX Constructors throw in the wrong context |
||||
Issue description
What steps will reproduce the problem?
function TestConstructor(type, lanes) {
var simdFn = SIMD[type];
// Check that we throw the Error for non-constructable object in the right
// Realm.
var realmIndex = Realm.create();
var otherTypeError = Realm.eval(realmIndex, "TypeError");
var remoteSimdFn = Realm.eval(realmIndex, "SIMD['" + type + "']" );
assertTrue(remoteSimdFn !== simdFn);
assertThrows(function() { new simdFn }, TypeError);
assertThrows(function() { new remoteSimdFn }, TypeError);
assertThrows(function() {
Realm.eval(realmIndex, "new SIMD['" + type + "']")
}, otherTypeError);
}
What is the expected output?
The TypeError thrown by "new remoteSimdFn" should be from the current Realm not the remote.
Currently we create the SIMD constructors in harmony-simd.js and manually throw if we're in a construct call. However this is not correct as according to http://tc39.github.io/ecma262/#sec-construct we have to throw before entering the constructor. The way to implement this is to make sure we set_is_constructor(false) on the SIMD constructors' maps (this requires adding another default map).
Hope this is more or less clear...
,
Nov 6 2015
,
Nov 9 2015
Why do you say that the SIMD constructors are not constructors? I don't know where this is indicated in the spec. I thought they were just functions which happened to throw if new.target is not undefined.
,
Nov 10 2015
Probably I jumped ahaed from reading http://tc39.github.io/ecmascript_simd/#simd-wrapper that the SIMDConstructors don't have an internal [[Construct]] method (which would probably be more consistent...). I see now the TypeError on a missing newTarget.
,
Nov 11 2015
Does anything have an internal [[Construct]] method besides classes and proxies? I think everyone just checks if new.target is undefined.
,
Nov 11 2015
For instance in http://tc39.github.io/ecma262/#sec-math-object the "non-construcability" of Math is mentioned through a missing [[Construct]] internal method (same for the global object btw). Of course from a user's perspective no much changes here, but it's quite inconsistent to where errors are thrown. Without Realms this is not an issue, but throwing before or after activating the callee context does make quite a difference there.
,
Nov 12 2015
I think this is a spec bug. When I've talked with Allen and others on the committee about why the spec sometimes checks for new.target === undefined and sometimes makes [[Construct]], the rationale was that there is no observable difference. Now I understand that their is, with this cross-realm issue. I wouldn't do eschatology on the spec to do the proper context based on which of the two patterns are used because it's genuinely arbitrary and not thought out and has nothing to do with proper security policy. Maybe instead we should ask for clarification from TC39 in the GitHub bug tracker. What do you think would be the better behavior here?
,
Nov 13 2015
Thanks Dan, I'd expect the check [[Construct]] to be the default, so that the internal IsConstructor() method can return false. This would also be in sync with %Math% or the global object, that's at least how I see it :).
,
Nov 13 2015
The %Math% this is rather odd; it is extra prose at the top of the definition. I initially added similar prose for the SIMD definition, but I was encouraged to remove it because it was duplication that added no value. Presumably, the committee viewed the text about %Math% the same way. At TC39 this week, I'll ask for clarification on what this all means--I think it was entirely unintentional.
,
Nov 13 2015
Filed a bug at https://github.com/tc39/ecma262/issues/174
,
Mar 23 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by adamk@chromium.org
, Nov 6 2015Owner: bbudge@chromium.org