Repository navigation
codegen: a dependent varip aggregate initializer sees its dependency's value at declaration time - #263
Merged
Conversation
… has when the declaration runs (#258) A varip UDT, array, map or matrix whose initializer reads a value computed by an earlier statement is initialized in the first-bar preamble, before that statement, and reads the zero default. The var form was fixed in #226. Adds the expectations: the emission order of the dependency and the declaration, the compiled run against the inline and var controls for each aggregate kind, that the first value is kept when the dependency changes later, that independent varip initializers keep their preamble, and, with a native engine, that the dependent value survives fill recalculations and the varip storage stays out of the rollback checkpoint. Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
…t order (#258) A varip UDT, array, map or matrix whose initializer reads a value computed earlier in the statement walk was initialized in the first-bar preamble and read the zero default. Route it onto the declaration-site once flag that the var form already uses (#226). The flag and the varip storage stay outside the calc_on_order_fills checkpoint and are reset for each new run, as for any varip member. Independent constructors, scalars and callable-scoped declarations keep their routes. Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
… order (#258) The CHANGELOG entry for the statement-order initializer said a varip declaration with the same dependency still read the default, and the AGENTS.md / CLAUDE.md rule listed varip among the paths left unchanged. With the varip route they no longer hold: say that varip takes the same route and that its storage and once flag stay out of the calc_on_order_fills rollback checkpoint. The rule paragraph keeps its line count. Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
The row asserted that a dependent varip aggregate keeps its first-bar preamble route, as a documented gap. With the statement-order fix the dependent initializer moves to its declaration site, so the row now fails by design. The new expectations for the same shapes (emission order, compiled run against the inline and var controls, first value kept, independent varip initializers keep their preamble) live in tests/test_varip_initializer_statement_order.py. Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
…tion (#258) The static test that the varip storage and its once flag stay out of the rollback checkpoint found the flag by pattern and passed without it when the pattern did not match. It now requires the flag the lowering of a persistent declaration names (the member's `_pf_var_init_` flag) in the guarded write before checking it against the checkpoint and the restore. The file's docstring also says what a wrong dependency looks like. Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
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.
What
A
varipaggregate (UDT, array, map, matrix) whose initializer reads a value computed by an earlier statement now initializes at its declaration, in statement order, like thevarform fixed in #226 (merged in #261). Before, it was initialized in the first-bar preamble, before that statement, and read the zero default.observedwas0; it is now1000, the same as the inline formvarip state = State.new(value=strategy.initial_capital / 100)and thevarform.How
The
varipdeclaration takes the same declaration-site route asvarwhen its initializer depends on an earlier statement (a two-line change in the statement-order check). Independent initializers and callable-scoped declarations keep their routes and their emission.varipstorage and its once flag stay outside thecalc_on_order_fillsrollback checkpoint, as before: a value set on the first bar survives a fill recalculation and the initializer runs once.Tests
varcontrols for each aggregate kind (UDT, array, map, matrix, UDT built by a helper), the issue's own script in the static and dynamic builds, and that the first value is kept when the dependency changes later. All of them fail onmain(the value is0against1000, or the declaration comes first).varipinitializers keep their preamble emission byte for byte.calc_on_order_fillsstrategy with a dependentvaripaggregate keeps its first value across fill recalculations (it reads0onmain), and a static test that thevaripstorage and its once flag stay out of the rollback checkpoint and the restore.main), 0 failed.main: none of them has a dependentvaripaggregate initializer.The CHANGELOG entry of #226 now says the
varipform takes the same route.Fixes #258
🤖 Generated with Claude Code