Severity: Low
Summary
#2655/PR #2904 added path-mode rows to scripts/perf-guard.py's instruction-count matrix, closing the "no row exercises resolve_node/resolve_node_sink at all" gap for del(), =, and path(). |= (compound update assignment) is not covered by any row, in either mode.
Why this needs its own row, not just adding |= to an existing filter
A naive |= row on a plain field target (e.g. .users[] | .score |= . + 1) would not actually close this gap: per needs_path_prepass (src/jq/eval.rs), a plain Identity/Field/Index/Slice/Iterate chain takes the single-path walkers (walk_path/set_path/set_path_steps/update_path/delete_at_path), not resolve_node/resolve_node_sink — this is exactly what PR #2904's own review discovered for users_assign_scores/users_path_walk (verified by direct instrumentation of resolve_node_sink: zero calls for either row). A |= row needs the same select/as-bound shape users_del_bound_select uses (matching #2042's own repro) to actually reach resolve_node_sink rather than re-covering the already-covered single-path walkers.
Suggested fix direction
Add a row along the lines of .users[] | select(.score < 100) | .score |= . + 1 (or an as-bound equivalent) to QUERIES in scripts/perf-guard.py, verified live against jq 1.7.1 for output identity first, then regenerate both arch baselines (terminus for x86_64, a native linux/arm64 Docker container on Apple Silicon for ARM64-Linux, matching #2655/#2904's own procedure) and confirm with a negative test (a temporary slowdown in resolve_node_sink) that the new row actually fails while a plain-target row does not — the same discipline #2904 used for its own rows.
Why this is separate from #2655/#2904
#2655's own scope was "no row exercises the resolver at all" — that's closed. This is a narrower residual within the fix: |= specifically remains unexercised, discovered during #2904's own code review rather than being part of the original issue's premise.
Dependencies / related
#2655 (closed by PR #2904), #2042 (the incident whose shape users_del_bound_select/this issue's suggested row both reproduce).
Severity: Low
Summary
#2655/PR #2904 added path-mode rows to
scripts/perf-guard.py's instruction-count matrix, closing the "no row exercisesresolve_node/resolve_node_sinkat all" gap fordel(),=, andpath().|=(compound update assignment) is not covered by any row, in either mode.Why this needs its own row, not just adding
|=to an existing filterA naive
|=row on a plain field target (e.g..users[] | .score |= . + 1) would not actually close this gap: perneeds_path_prepass(src/jq/eval.rs), a plainIdentity/Field/Index/Slice/Iteratechain takes the single-path walkers (walk_path/set_path/set_path_steps/update_path/delete_at_path), notresolve_node/resolve_node_sink— this is exactly what PR #2904's own review discovered forusers_assign_scores/users_path_walk(verified by direct instrumentation ofresolve_node_sink: zero calls for either row). A|=row needs the sameselect/as-bound shapeusers_del_bound_selectuses (matching #2042's own repro) to actually reachresolve_node_sinkrather than re-covering the already-covered single-path walkers.Suggested fix direction
Add a row along the lines of
.users[] | select(.score < 100) | .score |= . + 1(or anas-bound equivalent) toQUERIESinscripts/perf-guard.py, verified live against jq 1.7.1 for output identity first, then regenerate both arch baselines (terminusfor x86_64, a native linux/arm64 Docker container on Apple Silicon for ARM64-Linux, matching #2655/#2904's own procedure) and confirm with a negative test (a temporary slowdown inresolve_node_sink) that the new row actually fails while a plain-target row does not — the same discipline #2904 used for its own rows.Why this is separate from #2655/#2904
#2655's own scope was "no row exercises the resolver at all" — that's closed. This is a narrower residual within the fix:
|=specifically remains unexercised, discovered during #2904's own code review rather than being part of the original issue's premise.Dependencies / related
#2655 (closed by PR #2904), #2042 (the incident whose shape
users_del_bound_select/this issue's suggested row both reproduce).