You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
esid: pending was used to indicate a test for functionality that was accepted but not yet merged into the ECMA-262 main branch.
According to git grep there are 331 tests in the tree with esid: pending. At a quick inspection most of these are actually not pending anymore, so these should be audited and given a proper esid if appropriate.
Going forward we'd like to use two mechanisms to indicate tests for items that are pending to be merged into the spec. Stage 3 proposals or other big items should use feature flags, and we will add a list of feature flags that represent features that aren't yet merged into the spec. Every test with a feature flag in this list should be considered the same as if its esid was pending.
This way, we don't have to do manual bookkeeping of individual esids for proposals when they get merged, but are still free to use esid: pending to indicate small groups of tests corresponding to a needs-consensus PR that has reached consensus but isn't merged yet.
We should also document esid: pending in the instructions for executing tests — I wasn't aware of it before today.
The text was updated successfully, but these errors were encountered:
esid: pending
was used to indicate a test for functionality that was accepted but not yet merged into the ECMA-262 main branch.According to
git grep
there are 331 tests in the tree withesid: pending
. At a quick inspection most of these are actually not pending anymore, so these should be audited and given a properesid
if appropriate.Going forward we'd like to use two mechanisms to indicate tests for items that are pending to be merged into the spec. Stage 3 proposals or other big items should use feature flags, and we will add a list of feature flags that represent features that aren't yet merged into the spec. Every test with a feature flag in this list should be considered the same as if its
esid
waspending
.This way, we don't have to do manual bookkeeping of individual esids for proposals when they get merged, but are still free to use
esid: pending
to indicate small groups of tests corresponding to a needs-consensus PR that has reached consensus but isn't merged yet.We should also document
esid: pending
in the instructions for executing tests — I wasn't aware of it before today.The text was updated successfully, but these errors were encountered: