fix: restore section headers for mandatory capabilities

.github/workflows/cla_assistant.yml

@@ -13,16 +13,15 @@
     steps:
       - name: "CLA Assistant"
         if: (github.event.comment.body == 'recheck' || github.event.comment.body == 'I have read the Contributor License Agreement and I hereby accept the Terms.') || github.event_name == 'pull_request_target'
-        uses: cla-assistant/github-action@v2.3.1
+        uses: contributor-assistant/github-action@v2.6.1
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          PERSONAL_ACCESS_TOKEN : ${{ secrets.CLA_BOT_ACCESS_TOKEN }}
         with:
           remote-organization-name: qir-alliance
           remote-repository-name: data_storage
           branch: 'main'
           path-to-signatures: 'signatures/${{ github.event.repository.name }}/cla.json'
           custom-allsigned-prcomment: 'All Contributors have signed the CLA.'
           custom-pr-sign-comment: 'I have read the Contributor License Agreement and I hereby accept the Terms.'
           allowlist: user1,bot*
           # edit the path below (if needed) to point to the document containing the CLA that a contributor agrees to

.github/workflows/link_and_spell_check.yml

@@ -23,21 +23,18 @@
             Write-Host "Adding matcher $_...";
             Write-Host "::add-matcher::$_";
           }
       shell: pwsh
     - name: markdownlint-cli
-      # cspell:words nosborn
-      uses: nosborn/[email protected]
+      uses: nosborn/[email protected]
       with:
         files: .
         config_file: 'utils/md_lint_config.yml'
     - name: Markdown link check
-      # cspell:words gaurav
-      uses: gaurav-nelson/github-action-markdown-link-check@v1
+      uses: gaurav-nelson/[email protected]
       with:
         use-verbose-mode: 'yes'
       if: ${{ success() || failure() }}
     - name: "Check spelling in changed files"
-      # cspell:words streetsidesoftware
       uses: streetsidesoftware/cspell-action@v6
       with:
         inline: warning

specification/under_development/profiles/Adaptive_Profile.md

@@ -7,7 +7,7 @@
 well as contributors to the [targeting
 stage](../Compilation_And_Targeting.md#targeting) of the QIR compiler.
 
 The Adaptive Profile specifies supersets of the [Base
 Profile](./Base_Profile.md) that enable control flow based on mid-circuit
 measurements and classical computations while quantum resources remain coherent.
 A backend can support this profile by supporting a minimum set of features
@@ -20,7 +20,7 @@
 1. It can execute a sequence of quantum instructions that transform the quantum
    state.
 2. A backend must support applying a measurement operation at any point in the
    execution of the program. Qubits not undergoing the measurement should not
    have their state affected.
 3. A backend must be able to apply quantum instructions conditionally on a
    measurement outcome. Specifically, forward branching using the LLVM branch
@@ -51,15 +51,6 @@
 9. Multiple return points.
 <!-- markdownlint-enable MD029 -->
 
-<!-- Original version:
-7. Backwards branching to express control flow loops. Non-terminating loops
-   ("while"-loops) are not permitted within the Adaptive Profile, regardless of
-   the support for this optional feature. It is specifically not permitted to
-   have a loop that terminates only based on a measurement outcome.
-   Correspondingly, permitting for backward branching mostly makes sense when
-   the backend also supports computations on at least one classical data type.
--->
-
 The use of these optional features is represented as a [module
 flag](#module-flags-metadata) in the program IR. Any backend that supports
 capabilities 1-4, and as many of capabilities 5-9 as it desires, is considered
@@ -72,7 +63,7 @@
 
 ## Mandatory Capabilities
 
-**Bullet 1: Quantum transformations** <br/>
+### Bullet 1: Quantum transformations
 
 The set of available instructions that transform the quantum state may vary
 depending on the targeted backend. The profile specification defines how to
@@ -87,24 +78,24 @@
 the distinction between runtime functions and quantum instructions, can be found
 in this [document](../Instruction_Set.md).
 
-**Bullet 2: Measurements** <br/>
+### Bullet 2: Measurements
 
 As for the Base Profile, a measurement function is a QIS function marked with an
 [`irreversible` attribute](./Base_Profile.md#quantum-instruction-set) that
 populates a value of type `%Result`. The available measurement functions are
 defined by the executing backend as part of the QIS. Unlike the Base Profile,
 the Adaptive Profile relieves a restriction that qubits can only be measured at
 the end of the program and that no quantum operations can be performed after or
 conditionally on a measurement outcome.
 
 Within the Adaptive Profile, there are no restrictions on when these
 measurements are performed during program execution. Correspondingly, it must be
 possible to measure individual qubits, or subsets of qubits depending on the
 supported QIS, without impacting the state of the non-measured qubits.
 Furthermore, it must be possible to use the measured qubit(s) afterwards and
 apply additional quantum instructions to the same qubit(s).
 
-**Bullet 3: Forward Branching** <br/>
+### Bullet 3: Forward Branching
 
 Additionally, the Adaptive Profile requires that it must be possible to take
 action based on a measurement result. Specifically, it must be possible to
@@ -149,7 +140,7 @@
 for example when performing real-time error-correction as part of a quantum
 programs.
 
-**Bullet 4: Program output** <br/>
+### Bullet 4: Program output
 
 The specifications of QIR and all its profiles need to accurately reflect the
 program intent. This includes being able to define and customize the program
@@ -328,8 +319,6 @@
 reference](https://llvm.org/docs/LangRef.html#switch-instruction) for more
 information about the switch instruction.
 
-<!--FIXME: check that the entry point section allows for entry point arguments - global constants as the alternative? -->
-
 ### Bullet 9: Multiple Return Points
 
 A backend my choose to support multiple return points in an entry point
@@ -779,19 +768,6 @@
 expected type. How such an integer value is interpreted and specifically how it
 relates to hardware resources is ultimately up to the executing backend.
 
-<!--From prior version metadata:
-For non-constant integer and floating-point values the assumption is that while
-a `%Result*` may point to a valid memory location in RAM or some other memory
-pool, by default, instructions performed on virtual registers with these data
-types correspond to these values being stored in integer or floating registers
-when an instruction is executed. Before a virtual register is used in an
-instruction, there is no assumption that the value in the virtual register
-always corresponds to a physical register. For example, when considering
-register coloring, the virtual register, `%0`, in the QIR program may refer to a
-value stored in RAM for most of its lifetime before being loaded into a register
-when an instruction operates on `%0`.
--->
-
 The integer value that is cast must be either a constant, or a phi node of
 integer type if [iterations](#bullet-7-backwards-branching) are used/supported.
 If the cast value is a phi node, it must not directly or indirectly depend on
@@ -903,7 +879,7 @@
   %2 = and i1 %0, %1
   br i1 %2, label %then, label %continue
 
-then: 
+then:
   tail call void @__quantum__qis__x__body(%Qubit* nonnull inttoptr (i64 2 to %Qubit*))
   br label %continue
 

specification/under_development/profiles/Base_Profile.md

@@ -26,7 +26,9 @@ fundamentally consist of unitary transformations of the quantum state as well as
 measurements at the end of the program. More details about each of the bullets
 are outlined below.
 
-**Bullet 1: Quantum transformations** <br/>
+## Mandatory Capabilities
+
+### Bullet 1: Quantum transformations
 
 The set of available instructions that transform the quantum state may vary
 depending on the targeted backend. The profile specification defines how to
@@ -41,7 +43,7 @@ the QIS, recommendations for front- and backend providers, as well as the
 distinction between runtime functions and quantum instructions can be found in
 [this document](../Instruction_Set.md).
 
-**Bullet 2: Measurements** <br/>
+### Bullet 2: Measurements
 
 The second requirement should be taken to mean that a Base Profile compliant
 program does *not* apply instructions to a qubit after it has been measured;
@@ -54,7 +56,7 @@ to measure only a subset of all available qubits at a time.
 - Executing a Base Profile compliant program does not require support for
 applying quantum instructions dependent on measurement outcomes.
 
-**Bullet 3: Program output** <br />
+### Bullet 3: Program output
 
 The QIR specification and its profiles describe a mechanism to accurately
 reflect program intent with regard to program output. The Base Profile

specification/v0.1/2_Callables.md

@@ -1,6 +1,6 @@
 # Callables
 
-We use the term _callable_ to mean a subroutine in the source language.
+We use the term *callable* to mean a subroutine in the source language.
 Different source languages use different names for this concept.
 
 > [!NOTE]