mirror of https://github.com/tc39/test262.git
Add test for freezing of module namespace object (#3213)
Attempting to freeze the module namespace exotic object should not affect the `writable`-ity of the properties as that exercises the same `DefineOwnProperty` operation according to [`SetIntegrityLevel`](https://tc39.es/ecma262/#sec-setintegritylevel). @erights discovered a [bug in v8](https://bugs.chromium.org/p/v8/issues/detail?id=12240) where, while the `Object.freeze` operation throws, it actually makes exported properties non-writable one by one. At the request of @syg, I'm contributing a test against this behavior. The bug in v8 actually leads to a breakage of the objects invariants, however I'm not testing for that here as the root cause is the illegal freezing of the export.
This commit is contained in:
parent
8fad17a506
commit
5fee61c9e8
|
@ -114,3 +114,24 @@ assert.throws(TypeError, function() {
|
|||
{value: "module", writable: false, enumerable: false,
|
||||
configurable: false});
|
||||
}, 'Object.defineProperty: Symbol.toStringTag');
|
||||
|
||||
|
||||
// Indirect change requested through Object.freeze
|
||||
|
||||
// Try freezing more times than there are exported properties
|
||||
for (let i = 1; i < exported.length + 2; i++) {
|
||||
assert.throws(
|
||||
TypeError,
|
||||
function () {
|
||||
Object.freeze(ns);
|
||||
},
|
||||
"Object.freeze: " + String(i)
|
||||
);
|
||||
}
|
||||
|
||||
for (const key of exported) {
|
||||
const desc = Object.getOwnPropertyDescriptor(ns, key);
|
||||
assert.sameValue(desc.writable, true, String(key) + " writable");
|
||||
}
|
||||
|
||||
assert(!Object.isFrozen(ns), "namespace object not frozen");
|
||||
|
|
Loading…
Reference in New Issue