pineforge-codegen 0.10.0__tar.gz → 0.10.2__tar.gz

{pineforge_codegen-0.10.0 → pineforge_codegen-0.10.2}/.github/workflows/release.yml

@@ -124,7 +124,7 @@ jobs:
       # failure would leave npm shipping a version PyPI never got.
       - name: Publish to PyPI
         if: ${{ !inputs.dry_run }}
-        uses: pypa/gh-action-pypi-publish@cef221092ed1bacb1cc03d23a2d87d1d172e277b  # release/v1
+        uses: pypa/gh-action-pypi-publish@dc37677b2e1c63e2034f94d8a5b11f265b73ba33  # v1.14.2
 
       # Commit + tag + push AFTER PyPI succeeds. The `git push --tags` triggers
       # publish-pyodide.yml for npm (which re-runs the gate — defense in depth),

{pineforge_codegen-0.10.0 → pineforge_codegen-0.10.2}/CLAUDE.md

@@ -207,7 +207,7 @@ strategy. The taxonomy:
 | -------------------------------- | -------------------------------------------------------------------- |
 | `HARD_REJECT_FUNC`               | Calls with no PineForge semantics at all (e.g. `request.financial`). |
 | `HARD_REJECT_NAMESPACE`          | Whole-namespace rejects — currently EMPTY (the old `ticker.*` blanket reject became per-function `HARD_REJECT_FUNC` entries: `ticker.{renko,kagi,linebreak,pointfigure,new,modify}`; `ticker.inherit`/`ticker.standard` pass through, `ticker.heikinashi` allowed for the chart's own symbol). |
-| `DIVERGENT_VARS` (warning) / `DIVERGENT_VARS_ERROR` (reject) | Built-in variables whose value diverges from TV (e.g. `bar_index` warns); the ERROR subset (`last_bar_index` — would silently mis-alias to the CURRENT bar index) is rejected because the backtest would be silently wrong. |
+| `DIVERGENT_VARS` (warning) / `DIVERGENT_VARS_ERROR` (reject) | Built-in variables whose value can diverge from TV. `bar_index` and `last_bar_index` warn because they depend on the fed data window; `last_bar_index` lowers to the window's true final index. The ERROR subset is reserved for silent mis-aliases and is currently empty. |
 | `BARSTATE_APPROX_VARS` (warning) | Barstate flags PineForge approximates in batch mode.                 |
 | `STRATEGY_UNSUPPORTED_PARAMS`    | Per-strategy.* call kwargs that codegen drops silently.              |
 | `NOT_YET_FUNC`                   | Implementable but currently no codegen — reject loudly.              |

{pineforge_codegen-0.10.0 → pineforge_codegen-0.10.2}/PKG-INFO

@@ -1,6 +1,6 @@
-Metadata-Version: 2.4
+Metadata-Version: 2.5
 Name: pineforge-codegen
-Version: 0.10.0
+Version: 0.10.2
 Summary: PineScript v6 to C++ transpiler that targets the pineforge-engine runtime.
 Project-URL: Homepage, https://github.com/pineforge-4pass/pineforge-codegen-oss
 Project-URL: Issues, https://github.com/pineforge-4pass/pineforge-codegen-oss/issues

pineforge_codegen-0.10.2/VERSION

@@ -0,0 +1 @@
+0.10.2

{pineforge_codegen-0.10.0 → pineforge_codegen-0.10.2}/docs/codegen-coverage-gaps.md

@@ -76,3 +76,55 @@ were added to convert the most fragile defensive paths from
 silent-on-bug to loud-on-bug.
 
 No new follow-up work identified by this audit.
+
+## Residuals left open by the array-bounds guard (2026-07-25)
+
+`array.insert`, the 3-argument `array.fill`, and `array.slice` now reject an
+out-of-range index instead of emitting raw STL iterator arithmetic (undefined
+behaviour). Three questions the bounds work deliberately does NOT settle:
+
+1. **`array.slice` shares storage with its source; codegen deep-copies.**
+   The Pine v6 reference says "Changing the elements in a slice directly
+   changes the elements in the original array, and vice versa", while both
+   lowerings construct a fresh `std::vector` from the iterator range. Any
+   write through a slice (or through the source while a slice is live) is
+   therefore lost. Closing this needs a view/alias type over the receiver's
+   storage, not an index check, so it is a separate and much larger change.
+   The extent of the aliasing is itself unsettled: the reference sentence
+   says "an object from the slice", which is unambiguous for arrays of
+   reference-like elements (UDT instances) but does NOT establish that a
+   primitive `array<float>` slice aliases element-for-element. Pin that
+   against TradingView before designing the view type — the answer decides
+   whether the fix is "arrays of UDTs only" or "all arrays".
+
+2. **Inverted ranges (`index_from > index_to`) are rejected, not clamped.**
+   No evidence pins TradingView's behaviour for `array.fill(id, v, 2, 1)` /
+   `array.slice(id, 2, 1)`. Rejecting is the fail-closed choice and the
+   3-argument `fill` range form has no current corpus exposure, but a
+   TradingView probe could show TV treats it as an empty range instead.
+
+3. **Negative endpoints for `fill`/`slice` are rejected.** The reference
+   lists only `array.get`/`array.set`/`array.insert`/`array.remove` as
+   negative-indexing functions, so `fill`/`slice` follow `array.percentrank`
+   and reject. If TradingView in fact normalises them, this is an
+   over-rejection (a valid script fails to transpile), not a wrong result.
+
+## Residual left open by the request.security rebind guard (2026-07-25)
+
+`_scalar_rebinds` is keyed by BARE NAME with no scope resolution, mirroring
+the existing `_scalar_defs`. A divergent `:=` rebind of a *local* named `sym`
+inside a user function therefore also disqualifies an unrelated *global*
+`sym` used as a `request.security` symbol. That direction is fail-closed
+(over-rejection, never a silent wrong-symbol run), but a scoped symbol table
+would be the exact fix. A 788-source differential shows the over-rejection
+costs nothing on the current corpus.
+
+**Still open — the ternary branch hole (KI-47(a)).** `_is_current_symbol_expr`
+still accepts `cond ? "EXCH:OTHER" : syminfo.tickerid` because EITHER branch
+resolving to the chart symbol is enough. Tightening it to require BOTH
+branches is correct in principle but rejects
+`data/standard/doriannnq-tjr-v4-strategy`, whose alternate branch is
+unreachable at its declared input configuration (`smtSym` defaults to `""`)
+and which grades Excellent at 44/44 / 100% match. Closing this needs the
+checker to see the effective input configuration, which it currently cannot
+(see the analysis in the R6 handoff). Held deliberately, not overlooked.

{pineforge_codegen-0.10.0 → pineforge_codegen-0.10.2}/pineforge_codegen/__init__.py

@@ -4,6 +4,7 @@ from .lexer import Lexer
 from .parser import Parser
 from .analyzer import Analyzer
 from .codegen import CodeGen
+from .finite_ta_length import expand_finite_choice_extrema_lengths
 from .pragmas import extract_pf_trace_pragmas
 from .support_checker import check_support_or_raise
 
@@ -44,6 +45,7 @@ def transpile(pine_source: str, *, check_support: bool = True, filename: str = "
     ast = Parser(tokens, source=pine_source, filename=filename).parse()
     if check_support:
         check_support_or_raise(ast, filename=filename)
+    ast = expand_finite_choice_extrema_lengths(ast)
     ctx = Analyzer(ast, filename=filename).analyze()
     # Attach after analysis: pragma expressions are not part of the
     # program body, so the analyzer never inspects them; the codegen
@@ -81,6 +83,7 @@ def transpile_full(pine_source: str, *, check_support: bool = True,
     ast = Parser(tokens, source=pine_source, filename=filename).parse()
     if check_support:
         check_support_or_raise(ast, filename=filename)
+    ast = expand_finite_choice_extrema_lengths(ast)
     ctx = Analyzer(ast, filename=filename).analyze()
     ctx.pf_trace_pragmas = pragmas
     gen = CodeGen(ctx)