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:
Mathieu Hofman 2021-09-23 20:36:37 -03:00 committed by GitHub
parent 8fad17a506
commit 5fee61c9e8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 21 additions and 0 deletions

View File

@ -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");