Skip to content

Fix harness/sm/non262-strict-shell.js for strict mode#5008

Open
ivankra wants to merge 1 commit intotc39:mainfrom
ivankra:sm-strict
Open

Fix harness/sm/non262-strict-shell.js for strict mode#5008
ivankra wants to merge 1 commit intotc39:mainfrom
ivankra:sm-strict

Conversation

@ivankra
Copy link
Copy Markdown

@ivankra ivankra commented Mar 29, 2026

harness/sm/non262-strict-shell.js is problematic and causes discrepancies between different test262 runners in test/staging/sm/strict/ tests depending on minor implementation details of the runners.

Some (most?) test262 runners e.g. test262-harness + eshost, boa, execute tests by concatenating 'use strict' in strict mode, harness code and test code into a single file to be executed by the engine. This causes harness/sm/non262-strict-shell.js to be run in strict scope and breaks its eval-based testLenientAndStrict() method as eval() inherits strictness.

Others e.g. libjs test262-runner run harness code in a separate scope from test code and able to pass test/staging/sm/strict/ tests in both modes in this way. This is easy to do for a test262 runner integrated with an engine, but also an easy detail to miss for implementers (as evidenced by boa's test runner), and awkward to implement in a general eshost-style runner.

I propose fixing the harness code - wrap eval() which inherits strictness with a Function() which doesn't.

This code is broken when run in strict mode as eval() inherits strictness
from its scope and causes e.g. testLenientAndStrict() method to run
both parts in strict mode. Wrap eval() inside a Function() to properly
implement strict->sloppy transition.
@Ms2ger
Copy link
Copy Markdown
Contributor

Ms2ger commented Mar 30, 2026

Alternatively, maybe we could mark all tests using testLenientAndStrict and friends with the noStrict flag. WDYT?

@ivankra
Copy link
Copy Markdown
Author

ivankra commented Mar 30, 2026

Yes, either way works. I can rewrite PR instead to mark these tests as noStrict.

I also later noticed harness/sm/non262-expressions-shell.js has a similar problem - if the harness code is evaluated in strict scope, it breaks some of the destructuring tests. It can be also fixed in harness code (ivankra@19e6635) or by marking affecting tests as noStrict.

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