Qiskit / qiskit / 24900731149 / 1
88%
main: 88%

LAST BUILD BRANCH: clippy-1.97
DEFAULT BRANCH: main
Ran
Files 933
Run time 47s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 87.559% (-0.02%) from 87.574%
24900731149.1

push

github

web-flow 
Remove equality between Param::Obj and Param::ParameterExpression (#16084)

This commit fixes a mismatch in the Param::eq() method where a Python
object param was potentially viewed as equal to a ParameterExpression
param. When comparing a python object parameter with a
ParameterExpression it would convert the ParameterExpression into a
pyobject and then uses Python's == to evaluate the equality.
Historically this was something that was done because the
ParameterExpression object was also a Python object. However, since
the function was first written the source of truth for the inner
ParameterExpression has moved to Rust. We're never in a situation
anymore when a ParameterExpression parameter on an instruction should be
treated as a Python object.

While this legacy equality may seem harmless because the equality should
typically just evaluate to false (albeit slowly through Python's
equality check), there are edge cases where this is doing the incorrect
comparison. Primarily the bug that #16076 was fixing was not caught
initially because in tests this legacy logic was converting a
ParameterExpression that is a constant int expression with no symbols
to a Python int during the conversion of the expression to Python.
That was then being compared against a Param::Obj() of a true Python
int. The equality check would incorrectly assert the ParameterExpression
was the same as the python int. This is what masked the bug in #16076
because this differs from how the rust data model treats these
parameters.

104873 of 119774 relevant lines covered (87.56%)

981329.23 hits per line

Source Files on job 24900731149.1