ponder-lab / Hybridize-Functions-Refactoring / #2445

82%

main: 83%

push

github

Propagate the numpy shape descriptor across call boundaries so staticness resolves interprocedurally (#758)

* Propagate the numpy shape descriptor across call boundaries

The parameter-flow numpy precondition tracked a `ShapeDescriptor` (source tensor plus covered dimensions) only within a single frame: shape metadata passed as an argument into a callee, or returned from one, lost its descriptor, so a numpy sink in the other frame saw a null descriptor and staticness was unprovable. Thread the descriptor through the same interprocedural edges the taint already crosses: a shape-tainted argument seeds its descriptor onto the callee's parameter, and a callee returning a tracked shape carries its (possibly slice-narrowed) descriptor back to the call-site result, preferred over the all-dimensions extractor seed. Conflicting descriptors (across returns or call-graph targets) poison to `AMBIGUOUS_DESCRIPTOR`, and an untracked shape return drops the descriptor; the memo key now includes the descriptor seed.

`via_arg` (`testNumpyOnShapeArgumentToCallee`) is now permitted by a proven-static shape rather than the precision-favoring unprovable-shape fallback, closing the coverage gap of #754. New pins: `testNumpyOnDynamicShapeArgumentToCallee` (a provably-dynamic sliced dimension crossing into the callee's sink now declines) and `testNumpyOnShapeReturnedFromCallee` (a slice-narrowed descriptor carried back across the return boundary permits, where the all-dimensions fallback would wrongly decline).

Closes #756, closes #754.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01M4XLK81HCB6Vp1WQiRPafR

* Clarify the return-descriptor semantics and the extractor-seed fallback

Align `NumpyScanResult`'s Javadoc with the implementation: the return descriptor is also null when a returned shape lacks a descriptor, not only when nothing tracked is returned. Document at the call-site merge that dropping the return-flow... (continued)

39 of 42 new or added lines in 1 file covered. (92.86%)

2112 of 2589 relevant lines covered (81.58%)

0.82 hits per line