Prepare 1.1.0 release

docs/conf.py

@@ -32,7 +32,7 @@
 # The short X.Y version
 version = "1.1"
 # The full version, including alpha/beta/rc tags
-release = "1.1.0rc1"
+release = "1.1.0"
 
 language = "en"
 

docs/release_notes.rst

@@ -10,4 +10,4 @@ Qiskit |version| release notes
     `:earliest-version:` should be set to the rc1 release for the current minor release series. For example, the stable/1.1 branch should set it to 1.1.0rc1. If on `main`, set to the prior minor version's rc1, like `1.0.0rc1`.
 
 .. release-notes::
-   :earliest-version: 1.0.0rc1
+   :earliest-version: 1.1.0rc1

qiskit/VERSION.txt

@@ -1 +1 @@
-1.1.0rc1
+1.1.0

qiskit/circuit/classical/expr/__init__.py

@@ -43,7 +43,7 @@
 real-time variable, or a wrapper around a :class:`.Clbit` or :class:`.ClassicalRegister`.
 
 .. autoclass:: Var
-    :members: var, name
+    :members: var, name, new
 
 Similarly, literals used in expressions (such as integers) should be lifted to :class:`Value` nodes
 with associated types.

qiskit/primitives/__init__.py

@@ -51,7 +51,7 @@
 * a collection parameter value sets to bind the circuit against, :math:`\theta_k`.
 
 Running an estimator returns a :class:`~qiskit.primitives.BasePrimitiveJob` object, where calling
-the method :meth:`~qiskit.primitives.BasePrimitiveJob.result` results in expectation value estimates 
+the method :meth:`~qiskit.primitives.BasePrimitiveJob.result` results in expectation value estimates
 and metadata for each pub:
 
 .. math::
@@ -95,15 +95,15 @@
     #             [<psi2(theta2)|H2|psi2(theta2)>] ]
     job2 = estimator.run(
         [
-            (psi1, [H1, H3], [theta1, theta3]), 
+            (psi1, [H1, H3], [theta1, theta3]),
             (psi2, H2, theta2)
         ],
         precision=0.01
     )
     job_result = job2.result()
     print(f"The primitive-job finished with result {job_result}")
 
-    
+
 Overview of SamplerV2
 =====================
 
@@ -220,8 +220,8 @@
     #             <psi2(theta2)|H2|psi2(theta2)>,
     #             <psi1(theta3)|H3|psi1(theta3)> ]
     job2 = estimator.run(
-        [psi1, psi2, psi1], 
-        [H1, H2, H3], 
+        [psi1, psi2, psi1],
+        [H1, H2, H3],
         [theta1, theta2, theta3]
     )
     job_result = job2.result()
@@ -417,8 +417,10 @@
    DataBin
    PrimitiveResult
    PubResult
+   SamplerPubResult
    BasePrimitiveJob
    PrimitiveJob
+   Shaped
 
 Estimator V1
 ------------
@@ -464,12 +466,16 @@
     DataBin,
     PrimitiveResult,
     PubResult,
+    SamplerPubResult,
     EstimatorPubLike,
     SamplerPubLike,
     BindingsArrayLike,
     ObservableLike,
     ObservablesArrayLike,
+    Shaped,
 )
+
+
 from .estimator import Estimator
 from .primitive_job import BasePrimitiveJob, PrimitiveJob
 from .sampler import Sampler

qiskit/primitives/containers/__init__.py

@@ -24,3 +24,4 @@
 from .pub_result import PubResult
 from .sampler_pub import SamplerPubLike
 from .sampler_pub_result import SamplerPubResult
+from .shape import Shaped

qiskit/primitives/containers/bit_array.py

@@ -130,6 +130,7 @@ def __repr__(self):
         return f"BitArray({desc})"
 
     def __getitem__(self, indices):
+        """Slices the array along an existing axis of the array."""
         if isinstance(indices, tuple) and len(indices) >= self.ndim + 2:
             raise ValueError(
                 "BitArrays cannot be sliced along the bits axis, see slice_bits() instead."

qiskit/primitives/containers/shape.py

@@ -59,15 +59,15 @@ def __repr__(self):
         return f"{type(self).__name__}(<{self.shape}>)"
 
     @property
-    def shape(self):
+    def shape(self) -> tuple[int, ...]:
         return self._shape
 
     @property
-    def ndim(self):
+    def ndim(self) -> int:
         return len(self._shape)
 
     @property
-    def size(self):
+    def size(self) -> int:
         return int(np.prod(self._shape, dtype=int))
 
 

qiskit/providers/__init__.py

@@ -452,8 +452,45 @@ def get_translation_stage_plugin(self):
 efficient output on ``Mybackend`` the transpiler will be able to perform these
 custom steps without any manual user input.
 
+.. _providers-guide-real-time-variables:
+
+Real-time variables
+^^^^^^^^^^^^^^^^^^^
+
+The transpiler will automatically handle real-time typed classical variables (see
+:mod:`qiskit.circuit.classical`) and treat the :class:`.Store` instruction as a built-in
+"directive", similar to :class:`.Barrier`.  No special handling from backends is necessary to permit
+this.
+
+If your backend is *unable* to handle classical variables and storage, we recommend that you comment
+on this in your documentation, and insert a check into your :meth:`~.BackendV2.run` method (see
+:ref:`providers-guide-backend-run`) to eagerly reject circuits containing them.  You can examine
+:attr:`.QuantumCircuit.num_vars` for the presence of variables at the top level.  If you accept
+:ref:`control-flow operations <circuit-control-flow-repr>`, you might need to recursively search the
+internal :attr:`~.ControlFlowOp.blocks` of each for scope-local variables with
+:attr:`.QuantumCircuit.num_declared_vars`.
+
+For example, a function to check for the presence of any manual storage locations, or manual stores
+to memory::
+
+    from qiskit.circuit import Store, ControlFlowOp, QuantumCircuit
+
+    def has_realtime_logic(circuit: QuantumCircuit) -> bool:
+        if circuit.num_vars:
+            return True
+        for instruction in circuit.data:
+            if isinstance(instruction.operation, Store):
+                return True
+            elif isinstance(instruction.operation, ControlFlowOp):
+                for block in instruction.operation.blocks:
+                    if has_realtime_logic(block):
+                        return True
+        return False
+
+.. _providers-guide-backend-run:
+
 Backend.run Method
---------------------
+------------------
 
 Of key importance is the :meth:`~qiskit.providers.BackendV2.run` method, which
 is used to actually submit circuits to a device or simulator. The run method

releasenotes/notes/1.1/abstract-commutation-analysis-3518129e91a33599.yaml

@@ -1,12 +1,12 @@
 ---
-features:
+features_transpiler:
   - |
-    Extended the commutation analysis performed by :class:`.CommutationChecker` to only operate on
-    hardware circuits to also work with abstract circuits, i.e. each operation in
-    the input quantum circuit is now checked for its matrix representation before proceeding to the
-    analysis. In addition, the operation is now checked for its ability to be cached in the session
-    commutation library. For example, this now enables computing whether :class:`.AnnotatedOperation`
-    commute. This enables transpiler passes that rely on :class:`.CommutationChecker` internally,
-    such as :class:`.CommutativeCancellation`, during earlier stages of a default transpilation pipeline
+    Extended the commutation analysis performed by :class:`~.CommutationChecker` to also work with
+    abstract circuits, i.e. each operation in the input quantum circuit is now checked for its matrix
+    representation before proceeding to the analysis step. Previously, the commutation analysis was only
+    performed on physical circuits. In addition, each operation is now checked for its ability to be
+    cached in the session commutation library. For example, this now enables computing
+    whether :class:`.AnnotatedOperation` commute. This enables transpiler passes that rely on :class:`~.CommutationChecker` internally,
+    such as :class:`.CommutativeCancellation`, to run during earlier stages of a default transpilation pipeline
     (prior to basis translation).
 

releasenotes/notes/1.1/add-annotated-arg-to-power-4afe90e89fa50f5a.yaml

@@ -1,17 +1,19 @@
 ---
-features:
+features_circuits:
   - |
-    The methods :meth:`~qiskit.circuit.QuantumCircuit.power`,
-    :meth:`~qiskit.circuit.Gate.power`, as well as the similar methods
+    The methods :meth:`.QuantumCircuit.power`,
+    :meth:`.Gate.power`, as well as the similar methods on subclasses
     of subclasses of :class:`~qiskit.circuit.Gate`
     (such as of :class:`~qiskit.circuit.library.SGate`) all have an additional
-    argument ``annotated``.
+    have a new argument ``annotated`` which is used to return an :class:`.AnnotatedOperation`
+    object when applying a power to a gate or circuit.
     The default value of ``False`` corresponds to the existing behavior.
     Furthermore, for standard gates with an explicitly defined ``power`` method,
-    the argument ``annotated`` has no effect, for example both
+    the argument ``annotated`` has no effect.
+    For example, both
     ``SGate().power(1.5, annotated=False)`` and ``SGate().power(1.5, annotated=True)``
     return a ``PhaseGate``.
-    The difference manifests for gates without an explicitly defined
+    A difference in the value of ``annotated`` manifests for gates without an explicitly defined
     power method. The value of ``False`` returns a
     :class:`~.library.UnitaryGate`, just as before, while the value of ``True``
     returns an :class:`~.AnnotatedOperation` that represents the instruction