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

86%

main: 89%

push

github

Name the effect, not the transformation, when the axis blocks a signature (#955)

Code 18 reported "Can't reconfigure this function's input signature: its
body reads a tensor dimension the inferred signature leaves unspecified."
That sentence names an `input_signature` and asserts the tool cannot
change it. The function it fires on need not have one, and a reader took
it to mean an existing signature was being preserved.

Both cases reach the one sentence, which the guards settle without
needing an example. `canReconfigure` is `reconfigureOtherwiseViable &&
!unresolvedStaticallyReadAxes`, so whenever the axis condition holds the
add path and the adjudication path above are false by construction,
whatever the signature situation is. Control arrives here either way, and
this branch never consults `hasInputSignatureParam()`.

So the message was correct where a signature exists and misleading where
one does not, which is the case that occurs. It now branches: "Can't add
an input signature to this function" when none is supplied, and the
existing text when one is, since that text is right there. The
transformation is `RECONFIGURE` in both cases because it acts on the
decorator; the message describes the effect on the program instead, which
is where the old wording went wrong.

The two existing twins already cover both branches and now pin them:
`testReconfigureBlockedAxesAdd` is signature-less and
`testReconfigureBlockedAxes` supplies one. Verified by ablation rather
than assumed. With the fix, both pass. With the fix reverted and the
assertions kept, `testReconfigureBlockedAxesAdd` fails alone and the
supplied twin still passes, so the assertion discriminates the branch
rather than the message merely being present.

The add-versus-replace ambiguity in the name `RECONFIGURE` is deliberately
left alone. The name legitimately covers both paths, and renaming it would
touch the precondition and transformation matrix the tests assert against;
a message fix shou... (continued)

3 of 3 new or added lines in 1 file covered. (100.0%)

3635 of 4250 relevant lines covered (85.53%)

0.86 hits per line