Skip to content

Conversation

@takikawa
Copy link
Collaborator

This PR addresses some feedback on #233, in particular to move the decoding out of regular mapping decoding.

This new PR's approach has all the range mapping decoding done after regular mapping decoding. Initially all mappings have a [[IsRangeMapping]] of false. If there are range mappings encoded, then the next decode step will update the field to true for any range mappings.

If a range mapping is specified for a mapping that doesn't map an original location, or the offset is out of range, then an error is optionally thrown.

One semantics question: should it also optionally throw if the mapping has a [[Name]] too?

@takikawa takikawa changed the base branch from main to proposal-range-mappings November 13, 2025 21:47
@takikawa
Copy link
Collaborator Author

BTW: this also includes commits from #234 so that should be merged first, then I'll rebase this.

@takikawa takikawa force-pushed the range-mappings-refactor-decoding branch from 8b944c1 to fe6ab75 Compare November 14, 2025 04:43
  * Range mapping decoding happens separate of and after mapping decoding now
  * Mappings are updated in-place to add range mapping info
@takikawa takikawa force-pushed the range-mappings-refactor-decoding branch from fe6ab75 to 5b20f97 Compare November 14, 2025 22:37
@takikawa takikawa merged commit 1f349be into tc39:proposal-range-mappings Nov 14, 2025
3 checks passed
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