Move destination_pointer into ForkP#68
Merged
Merged
Conversation
The pointer expansion writes for a resolved Fork was a key loose on the element, beside `kind` and `length`. It belongs in the group with the parameters it resolves -- `to_line` and `destination_element` -- and with the `forked_to` name it becomes. handle_fork already has the ForkP node in hand, and both readers (run_element_bookkeeper's propagation seed and link_fork_connections) already look ForkP up for a sibling parameter, so each now reads the pointer from there too. remap_destination_pointers matches on the key alone and is unaffected by the depth. `destination_pointer` is deliberately not added to the check's ForkP vocabulary: that list is the spec's, and unlike `forked_to` this key is an implementation detail of expansion with no entry in fork.md. Writing one in input is a mistake worth reporting, and the check only ever sees `combined`, where the parser has not yet written any. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
The pointer expansion writes for a resolved Fork was a key loose on the element,
beside
kindandlength. It belongs in the group with the parameters itresolves --
to_lineanddestination_element-- and with theforked_toname it becomes.
handle_fork already has the ForkP node in hand, and both readers
(run_element_bookkeeper's propagation seed and link_fork_connections) already
look ForkP up for a sibling parameter, so each now reads the pointer from there
too. remap_destination_pointers matches on the key alone and is unaffected by
the depth.
destination_pointeris deliberately not added to the check's ForkP vocabulary:that list is the spec's, and unlike
forked_tothis key is an implementationdetail of expansion with no entry in fork.md. Writing one in input is a mistake
worth reporting, and the check only ever sees
combined, where the parser hasnot yet written any.
🤖 Generated with Claude Code