Skip to content
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

Remove a wrong test not to slow down test262-es2015 #4542

Merged
merged 1 commit into from
Jan 26, 2021

Conversation

ossy-szeged
Copy link
Contributor

Since ES2018 iterator's next method is called once during the prologue of iteration,
rather than during each step. The test is incorrect and stuck in an infinite loop.
tc39/test262#1248 fixed the test and it passes on test262-esnext.

Removing test/language/statements/for-of/iterator-next-reference.js from test262-es2015
is necessary, because it won't pass ever and only slow down testing.

JerryScript-DCO-1.0-Signed-off-by: Csaba Osztrogonác [email protected]

Since ES2018 iterator's next method is called once during the prologue of iteration,
rather than during each step. The test is incorrect and stuck in an infinite loop.
tc39/test262#1248 fixed the test and it passes on test262-esnext.

Removing test/language/statements/for-of/iterator-next-reference.js from test262-es2015
is necessary, because it won't pass ever and only slow down testing.

JerryScript-DCO-1.0-Signed-off-by: Csaba Osztrogonác [email protected]
@ossy-szeged
Copy link
Contributor Author

Note: It is needed to be able to increase timeout for debug tests. (#4456)
Telling the truth, this workaround isn't nice, but unfortunately there is no other way to ignore this test.

@zherczeg
Copy link
Member

If we land this, and move to another test262 version, will there be a notification to remove this workaround?

@ossy-szeged
Copy link
Contributor Author

If we land this, and move to another test262 version, will there be a notification to remove this workaround?

It affects only the es2015 version of test262 which is a fixed git revision.
The esnext version of test262 already contains the fixed test and it passes.

We can drop this workaround when we drop es2015 version of test262.

@zherczeg
Copy link
Member

Do we still need it? We don't have es2015 support anymore.

@ossy-szeged
Copy link
Contributor Author

Do we still need it? We don't have es2015 support anymore.

I don't think if we should drop test262-es2015 until we make all supported feature compatible with ES11 (ES2020),
there are still ~1000 uncategorized test failures in test262-esnext exclude list. Now we know that we are at least
compatible with the older ES2015 spec. If we dropped it, we wouldn't know if these features are compatible with any spec.

Copy link
Member

@zherczeg zherczeg left a comment

Choose a reason for hiding this comment

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

LGTM

@lygstate
Copy link
Contributor

lygstate commented Jan 26, 2021

Do we still need it? We don't have es2015 support anymore.

I don't think if we should drop test262-es2015 until we make all supported feature compatible with ES11 (ES2020),
there are still ~1000 uncategorized test failures in test262-esnext exclude list. Now we know that we are at least
compatible with the older ES2015 spec. If we dropped it, we wouldn't know if these features are compatible with any spec.

Hi, maybe using a exclude-list and pass into test262-harness instead? All tests that failed because upgrade to es2020 should be
disabled in testing procedure.

@ossy-szeged
Copy link
Contributor Author

Hi, maybe using a exclude-list and pass into test262-harness instead?

On the CI we always run tests with update option (to see not only regressions, but progressions too), which doesn't use exclude list at all.

@lygstate
Copy link
Contributor

Hi, maybe using a exclude-list and pass into test262-harness instead?

On the CI we always run tests with update option (to see not only regressions, but progressions too), which doesn't use exclude list at all.

Make sense, after this pull request, we can increase the timeout value to a very large value such as 5minutes,

LGTM

Copy link
Contributor

@lygstate lygstate left a comment

Choose a reason for hiding this comment

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

LGTM

@rerobika rerobika merged commit e081cbc into jerryscript-project:master Jan 26, 2021
@ossy-szeged ossy-szeged deleted the fix-test262-es2015 branch January 7, 2022 11:02
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.

4 participants