Skip to content

Conversation

@d01c2
Copy link

@d01c2 d01c2 commented Jan 1, 2026

This PR adds coverage for the case where ToUint16 produces an abrupt completion because its initial ToNumber step throws. (ToUint16 step 1)

String.fromCharCode converts each argument with ToUint16, and ToUint16 begins by applying ToNumber. So if the argument triggers an abrupt completion during ToNumber, that abrupt completion must be observable at the String.fromCharCode call site.

String.fromCharCode is a representative builtin that exercises ToUint16, so String.fromCharCode(0n) is a straightforward way to cover this path: ToNumber(0n) throws, and the builtin must propagate that error.

More generally, should test262 aim to add similar coverage for other observable abrupt-completion paths that currently aren’t covered? Or is there a consensus in test262 to keep this kind of coverage limited to a few representative cases?

@d01c2 d01c2 requested a review from a team as a code owner January 1, 2026 07:22
Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think this could also have a non-bigint test that ensures that passing { valueOf: function () { throw new Test262Error(); } } throws the proper error type

@d01c2
Copy link
Author

d01c2 commented Jan 2, 2026

I agree with your suggestion. I’ll add a test for that case right away.

@ptomato
Copy link
Contributor

ptomato commented Jan 5, 2026

More generally, should test262 aim to add similar coverage for other observable abrupt-completion paths that currently aren’t covered? Or is there a consensus in test262 to keep this kind of coverage limited to a few representative cases?

Ideally, we'd have a similar test for every place ToUint16 is called. JS engines are not under any obligation to structure their code the same way the specification is structured, so they might not use the same ToUint16 code path everywhere the spec has a ToUint16 operation. But 100% coverage of every operation would not be realistic, and in practice engines probably all have a ToUint16 operation so after a certain point we get diminishing returns. It's just a matter of priorities and what people are willing to contribute. Certainly we wouldn't reject a PR that added more similar tests in additional places where ToUint16 is called.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants