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

85%

main: 86%

push

github

Withhold a signature for an unrepresentable container element (#938)

* Withhold a signature for an unrepresentable container element

A container reaching a parameter can hold an element no `TensorSpec`
admits, Python `None` being the case this covers. A specification is a
universal claim over the values that arrive, so a single unrepresentable
member defeats it however many legitimate tensor members sit beside it,
and whether or not the branch that would supply a tensor ever runs.

The whole function is blocked rather than the position narrowed or
dropped. A specification covering fewer positions than the call supplies
is rejected on arity, and one naming a tensor where `None` arrives is
rejected on type, so either would be a different unsatisfiable artifact
rather than a repair.

The element's own type evidence cannot reveal this. The null and the
tensor state meet on ONE field key when a variable is initialized to
`None` and only then conditionally reassigned, so a phi carries both
into the container and the reduction, which reads only the tensor
variable's types, sees a well-formed element. The key's points-to set
has to be asked separately.

The fixture's geometry is therefore load-bearing, and a simpler one
reproduces nothing: two elements in different positions give one
position the null and the other the array, and both of those are already
handled. Its guard is data-dependent so the branch that is dead at run
time cannot be pruned. The sibling control allocates both elements
unconditionally and must keep its signature; before this change the two
emitted byte-identical specifications, so a change blocking both would
have looked like a success while destroying a correct emission.

The null test is local for now and names the engine-side predicate that
replaces it, stating that the predicate answers the `None` question only
and does not judge other unrepresentable members.

* Find the unrepresentable element without scanning every pointer key

... (continued)

19 of 19 new or added lines in 3 files covered. (100.0%)

3608 of 4225 relevant lines covered (85.4%)

0.85 hits per line