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

Fix test case for binding expression ranges #2

Closed
wants to merge 1 commit into from

Conversation

jridgewell
Copy link

When parsing a binding set, the names index is first, then a peek for M, then (M-1) parses of line/col/name.

The old test code cases DFGCAI decodes to -1, -2, 3, 1, 0, 4. The D decodes the first param's unavailable expression. Then we move on to the second param's initial names index, which decodes F (-2). But -2 is not a valid names index, it looks like we mixed the M and names order.

When parsing a binding set, the `names` index is first, then a peek for `M`, then (M-1) parses of `line`/`col`/`name`.

The old test code cases `DFGCAI` decodes to `-1`, `-2`, `3`, `1`, `0`, `4`. The `D` decodes the first param's unavailable expression. Then we move on to the second param's initial `names` index, which decodes `F` (`-2`). But `-2` is not a valid names index, it looks like we mixed the `M` and `names` order.
@hbenl
Copy link
Owner

hbenl commented Jun 28, 2024

We've changed the spec to put the number of binding ranges before the names index of the first binding expression in tc39/ecma426#106, which is what the implementation in this repo already did. This also makes parsing the bindings slightly simpler.

@hbenl hbenl closed this Jun 28, 2024
@jridgewell jridgewell deleted the patch-1 branch June 28, 2024 21:52
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