Fix qpy serialization of substitution of type ParameterExpression

[jlapeyre]

When substitution history ParameterExpression._qpy_replay is serialized, there was no branch for the case that the substituted value is of type ParameterExpression.

This commit fixes this oversight.

• I have added the tests to cover my changes.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.

Tests need to be added.

Closes #13879

[coveralls]

Pull Request Test Coverage Report for Build 13427794082

Details

• 13 of 13 (100.0%) changed or added relevant lines in 1 file are covered.
• 5 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.002%) to 88.103%

---

Files with Coverage Reduction	New Missed Lines	%
crates/accelerate/src/unitary_synthesis.rs	2	94.29%
crates/qasm2/src/lex.rs	3	91.98%

Totals
Change from base Build 13421430619:	-0.002%
Covered Lines:	78358
Relevant Lines:	88939

---

💛 - Coveralls

[jlapeyre]

EDIT: Fixed in fa0d254

As it stands, this PR is not an adequate fix because, although, serialization does not error, deserialization of the result does error.

It looks like the current fix is inadequate because the value of a symbol in the replay is assumed to not be a ParameterExpression. In particular, the header written will not correspond to the data written. Both strings and numbers are written. Since the header is nonsense, an attempt is made to read numeric data into a string, which results in an invalid utf8 codec.

[qiskit-bot]

One or more of the following people are relevant to this code:

• @Qiskit/terra-core
• @mtreinish
• @nkanazawa1989

[jlapeyre]

I ported this to Qiskit v1.3.2 and verified that it works.

On the main branch, I can't test with qiskit-ibm-runtime, because it is incompatible with the qiskit development branch.

The fix applied to the stable release Qiskit v1.3.2 is not worth much, because deserializing on the server end fails of course. It will need to be updated, too.

Because of this, it looks like this will require a version bump in qpy.

[mtreinish]

Overall this LGTM, I left one small comment inside about trying to minimize the diff for backport reasons. The other thing which might be good is adding a backwards compatibilty test to https://github.com/Qiskit/qiskit/blob/main/test/qpy_compat/test_qpy.py to cover this case so that we ensure we can load payloads with these types of expressions from qiskit >= 1.4.1 with QPY 13.

Because of this, it looks like this will require a version bump in qpy.

I'm on the fence about this. From the way the format spec is written this was just an oversight in the implementation so I view it as a straight bug in the v13 implementation that neither serialization or deserialization works with nested substituted parameter expressions. But your also correct that no v13 implementation out there works with this model yet which makes it feel like doing this in v14 is a better choice.

I'm inclined to just leave this as a v13 fix, and not require v14 for it since the format is still parsable in v13, it will just error because of the deserialization bug.

[mtreinish]

Do you mind reverting the name change here? I agree with the change in the naming, but since we're probably going to backport this PR for 1.4.1 I think it's better to minimize the diff to reduce the risk of regression. So we can keep the change here to just the functional component below adding the missing handling of the PARAMETER_EXPRESSION type in the extra expression/symbols.

We can do the renaming in a standalone PR that we don't backport.