Summary
A qvar_define op with no size field is handled two different ways inside pecos-phir-json: the JSON-to-PHIR converter rejects it, and the classical interpreter treats it as size zero.
Detail
The v0.1 specification lists size as required for a quantum declaration (crates/pecos-phir-json/specification/v0.1/spec.md around line 141). After the #819 fix the converter enforces that; the interpreter's declaration handling still infers zero and continues, so the same malformed program is rejected on one entry point and silently accepted on the other, with every subsequent index into that register out of bounds.
Related, from the same review: a qvar_define whose data_type is not "qubits" is now rejected by the converter (matching the Python reference, which raises), but the processor path still accepts identical duplicate declarations where the converter and interpreter reject them. The declaration-validation rules are not stated in one place.
Expected
One declaration-validation routine that every entry point calls, so a malformed or duplicate quantum declaration is accepted or rejected identically everywhere, with the rules written next to that routine. Where PECOS deliberately diverges from the Python reference (Python overwrites a duplicate name; PECOS refuses), the divergence belongs in that one place as a comment, not spread across call sites.
Provenance
Surfaced while fixing #819: the fix made the converter strict and the arm reported the interpreter's inconsistency rather than widening its scope. Not a regression.
Summary
A
qvar_defineop with nosizefield is handled two different ways insidepecos-phir-json: the JSON-to-PHIR converter rejects it, and the classical interpreter treats it as size zero.Detail
The v0.1 specification lists
sizeas required for a quantum declaration (crates/pecos-phir-json/specification/v0.1/spec.mdaround line 141). After the #819 fix the converter enforces that; the interpreter's declaration handling still infers zero and continues, so the same malformed program is rejected on one entry point and silently accepted on the other, with every subsequent index into that register out of bounds.Related, from the same review: a
qvar_definewhosedata_typeis not"qubits"is now rejected by the converter (matching the Python reference, which raises), but the processor path still accepts identical duplicate declarations where the converter and interpreter reject them. The declaration-validation rules are not stated in one place.Expected
One declaration-validation routine that every entry point calls, so a malformed or duplicate quantum declaration is accepted or rejected identically everywhere, with the rules written next to that routine. Where PECOS deliberately diverges from the Python reference (Python overwrites a duplicate name; PECOS refuses), the divergence belongs in that one place as a comment, not spread across call sites.
Provenance
Surfaced while fixing #819: the fix made the converter strict and the arm reported the interpreter's inconsistency rather than widening its scope. Not a regression.