Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A few small fixes which stuck out to me as I was reading it that may be useful:
Talk about measuring qubits not affecting others' states if taken literally meant that all qubits in a system never affected each other no matter their level of entanglement or relation on a measure. While I'm unfamiliar with anything but superconducting for hardware nuance, and it's likely its implied that a 'measure' is the collective measurement of all associated qubits, this is definitely one I had some questions around. Unless it's an assumption that mid-circuit measurements in the future just peek at the result without actually collapsing the qubits state? Either way, some additional clarification - whether it's my change or not - would likely help a ton here I feel.
Moved phi node into its own section as it's around looping/branching and not about integers (directly at least). I also gave it a more understandable description, as while I know the previous one was taken directly from the manual unless you know what a phi node does already that description will not help your understanding.
The talk about phis moving data around and returns in my opinion complicates things. I'm pretty sure you can have if-return blocks that immediately jump in a straight line without phis since there's no variables to merge, and this becomes way more complicated if you have sub-functions too. For now I've tried to restrict it to if everything is in a single function to avoid the latter, but I feel this section would be a bit clearer of this sentence was removed.
General notes or things which require rewriting whole sections which I wouldn't do without peoples agreement beforehand:
Section 7 about optional loops/iterations focuses a bit too much on phi nodes when it's about loop unrolling and having constantly-evaluable data flowing in and out, at least for the non-conditional ones. Focusing on that and going a bit higher level will help bring to the fore precisely the restrictions you have on looping and what the intention around them are without having to read a few paragraphs in.
If this profile wants to make all entry-point return values are error codes, and it claims the ones between 0-64 are QIR-related, better to set some in stone before people sneakily start claiming some. At a first read it seemed that there were a few baseline ones, rest are for you to do with as you will which will cause some glorious chaos down the line.