Repository navigation
app: an entity may have an edge to its own type - #2
Merged
Merged
Conversation
A Select selects each edge's far end with that entity's own Select, so an entity with an edge to its own type -- a tree's parent -- asks for its Select while writing it. defineMsg caches a message only once its body returns, and the second ask arrives through a fresh fileWork, since withEntity makes one per reference; neither cache saw it, and generation recursed until the stack ran out. Two entities of one file with edges to each other were the same cycle one step longer. The names being defined are now kept on the work they share, and asking for one of them answers its name: a message may contain itself, and the definition in progress is the one that is emitted. The pair also needed every entity's output path before any entity is written. Paths were registered as each entity's turn came, so the first of two that point at each other could not say where the second's messages are; they are now all registered first. Fixes #1. Co-Authored-By: Claude Opus 5.5 <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
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.
Fixes #1.
What was wrong
xMsgSelectselects each edge's far end with that entity's ownSelect, so an entity with an edge to its own type asks for itsSelectwhile writing it.defineMsgcaches a message only after its body returns, and the second ask arrives through a freshfileWork(withEntitymakes one per reference), so neither cache saw it and generation recursed until the stack ran out. Two entities in one file that point at each other were the same cycle one step longer.What this changes
app/work.go: the names being defined are kept on the sharedwork; asking for one while its body is being written answers its name. A protobuf message may contain itself, and the definition already in progress is the one that is emitted.app/app.go: every entity's output path is registered before any entity is written. For the pair, the first of the two could not otherwise say where the second's messages are (generated filepath to the entity not found).proto/apptest/tree.proto: aNodewith aparentedge to itself, and aLeft/Rightpair pointing at each other, with the contract they generate.internal/apptest: a test that the contract hasNodeSelect parent = 16, that the pair select each other, thatNodeSelectis written once, and that the file does not import itself.The four existing contracts do not change.
Checked
What CI runs, locally:
buf generatetwice with no diff (the second pass compiles the new contract),gofmt,go build,go vet,go test ./... -count=1.🤖 Generated with Claude Code