-
Notifications
You must be signed in to change notification settings - Fork 479
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make resizableArrayBufferUtils not depend on syntax that may not be supported #4165
Make resizableArrayBufferUtils not depend on syntax that may not be supported #4165
Conversation
ed53e08
to
3b42b6c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. This time I made sure the resizable ArrayBuffer tests do still run on implementations that support them 😅
3b42b6c
to
336115d
Compare
// Using new Function()(); instead of just 'class x extends Y' as to not bomb out when `class` isn't supported | ||
const MyUint8Array = new Function('return class MyUint8Array extends Uint8Array {}')(); | ||
const MyFloat32Array = new Function('return class MyFloat32Array extends Float32Array {}')(); | ||
const MyBigInt64Array = new Function('return class MyBigInt64Array extends BigInt64Array {}')(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it ok that these exceptions aren't caught?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sigh, no, they are not. I'm sorry, juggling too many things at once and trying to rush it through, shouldn't have done that...
Will send an additional PR tomorrow... Sorry again for keeping you all occupied...
Added catch to achieve the entire goal of the previous PR to prevent the harness from loading if 'class' syntax isn't supported
Added catch to achieve the entire goal of the previous PR to prevent the harness from loading if 'class' syntax isn't supported
In order to not fail because harness code fails to load due to using not-supported EcmaScript features while not needed
Relates to ##3032