Skip to content

test(js): match negative type Test262Error by constructor name#87

Open
codymullins wants to merge 2 commits into
mainfrom
fix/test262-runner-negative-type
Open

test(js): match negative type Test262Error by constructor name#87
codymullins wants to merge 2 commits into
mainfrom
fix/test262-runner-negative-type

Conversation

@codymullins

Copy link
Copy Markdown
Collaborator

What

Every Test262 negative test with type: Test262Error was scored as a failure even though the engine ran them correctly:

language/line-terminators/comment-single-cr.js :: expected Test262Error, threw Error

Root cause — harness false negative, not an engine bug

The runner's ErrorName classified a thrown error by reading the instance's name property. Built-in errors expose their type that way (TypeError.prototype.name and friends), but the harness's Test262Error (defined in sta.js) is a plain function that sets only message — its instances have no name anywhere on the prototype chain. So ErrorName returned null, the negative-type match failed, and FormatThrow defaulted the display to "Error".

These tests put a line terminator (CR / LF / U+2028 / U+2029) inside or after a comment, then throw new Test262Error() on the next line. The engine was terminating the comment correctly — the throw ran (that's why we saw "threw", not "no throw"); the runner just mislabeled the thrown type.

Fix

When the thrown instance has no name, fall back to its constructor's name — which is what the official test262 runner matches a negative type against. The change is additive: built-in-error tests already have .name, so their matching is unchanged.

Result (Test262, language scope)

Category Before After
language/line-terminators 68/82 — 82.9% 82/82 — 100.0%
language/module-code 537/584 539/584 (+2)

+16 scenarios total, all from correctly recognizing Test262Error — exactly the 9 type: Test262Error files in the language scope (7 line-terminators + 2 module-code), each in its run modes.

Remaining module-code failures are unrelated genuine engine gaps (module name binding, TDZ, namespace internals) — out of scope here.

The Test262 runner classified a negative test's thrown error by reading the instance's name property. Built-in errors expose their type that way (TypeError.prototype.name and friends), but the harness Test262Error is a plain function that sets only message, so its instances have no name. Every test with 'negative type: Test262Error' was therefore scored as a failure (expected Test262Error, threw Error) even though the engine threw the right error and terminated the comment correctly.

Fall back to the thrown value's constructor name when the instance has no name, which is what the official test262 runner matches against. The engine was already correct. This removes a harness false negative.

language/line-terminators: 82.9% -> 100.0% (68/82 -> 82/82). language/module-code: +2 (the two Test262Error module tests).
Copilot AI review requested due to automatic review settings June 16, 2026 21:10

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Add unit tests for the runner's ErrorName: a Test262Error instance (no name property) resolves by its constructor name, a built-in error still resolves by name, an own name wins over the constructor name, and a thrown primitive has no error name. ErrorName is relaxed to internal so the test in the same assembly can call it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants