format: clarify inline activation reconstruction (push/pop vs membership)#233
Merged
Merged
Conversation
…hip) Amend the invoke spec's "Reconstructing activations" section to resolve an ambiguity #230's inline pass exposed: an inlined body's invoke/return markers must bracket the body (invoke on the first instruction, return on the last), never duplicate across interior instructions. Duplicated boundary markers push/pop spurious activations. - State the push/pop display semantics: invoke opens inclusive of its instruction, return closes after its instruction. - Require bracketed emission; permit the single-instruction body (entry==exit) to carry both invoke and return, processed push-then-pop. - Separate the two concerns explicitly: push/pop determines an activation's lifetime; membership determines which open activation an instruction belongs to. An activation stays open across non-member (interleaved caller) instructions. No schema change.
Contributor
|
This was referenced Jul 3, 2026
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.
Amends the
invokespec's "Reconstructing activations" section to close an ambiguity that #230's inline pass exposed end-to-end. This is a spec-wording change only — no schema change.Why
ui's verification of #230 found the docs tracer mis-renders inline virtual activations (call stack never pops; phantom
dbl > dblframes). Root cause: downstream O2 passes smear theinvokeandreturnbracket markers across every instruction of an inlined body, and the spec didn't explicitly forbid that or separate the two reconstruction concerns. This amendment makes the contract unambiguous so both the compiler (emission) and the UI (reconstruction) have a firm reference.What changes
invokegoes on the first instruction of a body,returnon the last. Compilers must not duplicate either across interior instructions — repeating them pushes/pops spurious activations.invokeandreturnon that one instruction; a debugger processes them push-then-pop (same pattern a tailcall back-edge already uses).invokeopens an activation inclusive of its instruction;returncloses it after its instruction (the return instruction is still inside the activation).transform:["inline"]membership determines which open activation an instruction belongs to. An activation stays open across non-member (interleaved caller) instructions, which are attributed to the enclosing activation.Companion PRs into
transform-context: compiler de-smears the emission to boundary instructions; ui implements push/pop + membership-attribution reconstruction with an inline chip (task #23).