Repository: Qiskit/qiskit

Issue:
Documenting backend upgrades needed for Store in 1.1.0
 Let just go with documenting this for now as part of the 1.1.x final documentation, I'll convert this into an issue to track. Both as an upgrade note in the final release notes and also as a guidance in the writing a backend section of the docs.

I think for 1.2.x we can look at adding a global flag in the target for something like supports store, etc to provide a high level indicator for this kind of capability above the per instruction look ups. We'd probably need to do this into an opt-in way (so it defaults true) but I think having the capability to express this in the target is what we'll want longer term.

_Originally posted by @mtreinish in https://github.com/Qiskit/qiskit/pull/12322#discussion_r1587689375_
            


Discussion:

Resolving patch:
diff --git a/qiskit/circuit/classical/expr/__init__.py b/qiskit/circuit/classical/expr/__init__.py
--- a/qiskit/circuit/classical/expr/__init__.py
+++ b/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.
diff --git a/qiskit/providers/__init__.py b/qiskit/providers/__init__.py
--- a/qiskit/providers/__init__.py
+++ b/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


Test patch: