Range mappings: refactor decoding out of mapping decoding #235
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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?