Add reference for asm-goto #1693
Conversation
ehuss
added
S-waiting-on-stabilization
|
@Amanieu: What do you think? |
|
@rustbot author |
rustbot
added
S-waiting-on-author
|
We reviewed this in the lang call today. Everyone read through it. It looked right. Nobody had any notes. |
|
In reading this more carefully (especially the lines not changed), I find myself wanting to double check that we're being precise enough now by what we mean by "the So when we say, e.g., that...
...or...
...or...
...or even...
...do we mean for these to apply to the |
GCC manual says "Also note that an asm goto statement is always implicitly considered volatile.", although AFAIU it's possible to represent a asm-goto in LLVM without the It's not clear what exactly is pure for an asm goto block, since the control flow change is also one of its output. We probably should just forbid pure + label from being used together -- however note that since
These would just mean the assembly themselves. |
How about replacing " |
Sounds about right, assuming that's correct in each use, which of course should be carefully checked. Everywhere that the word "block" is used should be reviewed during this rename. |
This comment has been minimized.
This comment has been minimized.
nbdd0121
force-pushed
the
master
branch
2 times, most recently
from
cc990ed to
040fc58
Compare
The asm-goto-with-outputs is still unstable, so in the reference it's still mentioned as forbidden by a check rule.
The latter now only means the entire block, while the former means the assembly code specified within the block (thus excluding `label` blocks).
Co-authored-by: Alice Ryhl <[email protected]>
|
@joshtriplett Indicated they could give a review over the chapter to make sure everything still fits together. |
|
I reviewed the entire chapter, and wrote nbdd0121#1 as a PR to this PR branch, since there were changes in areas outside the context of the patch, which github doesn't allow suggestions in. I added some more disambiguations in cases of possible ambiguity between the entire asm! block (including label blocks) and the assembly code within it. The second commit, which I've kept separate, attempts to clarify an interaction between noreturn and label blocks; however, for that commit I could use some confirmation on accuracy. The phrasing as previously written said that "A noreturn asm block behaves just like a function which doesn't return", but that isn't accurate in the presence of label blocks, since the asm block can return, from the label blocks. I changed it to apply to "A noreturn asm block with no label blocks". However, this assumes there are not more semantic connotations of noreturn here that do apply to asm blocks with label blocks. With the first commit applied, and either the second commit (if accurate) or something like it (if another phrasing would be more accurate) applied, the chapter looks fully consistent to me. |
Update more cases where the phrasing could potentially have been interpreted as affecting a `label` block.
Let's make some clarifications of substance and editorial tweaks to the changes for `asm_goto`. We add an example, we change various wording to be more clear -- in particular, we significantly revise the section on `noreturn` to unify the statement of the rules -- and we replace remaining uses of "asm code" with "assembly code" to match our verbiage elsewhere. The main clarification of substance is that for requirements that must be upheld when falling through the assembly, such as he requirement to restore the stack pointer, we must also note that the requirement must be satisfied before jumping to any `label` blocks.
traviscross
removed
the
S-waiting-on-author
…rcote Stabilize `asm_goto` feature gate Stabilize `asm_goto` feature (tracked by rust-lang#119364). The issue will remain open and be updated to track `asm_goto_with_outputs`. Reference PR: rust-lang/reference#1693 # Stabilization Report This feature adds a `label <block>` operand type to `asm!`. `<block>` must be a block expression with type unit or never. The address of the block is substituted and the assembly may jump to the block. When block completes the `asm!` block returns and continues execution. The block starts a new safety context and unsafe operations within must have additional `unsafe`s; the effect of `unsafe` that surrounds `asm!` block is cancelled. See rust-lang#119364 (comment) and rust-lang#131544. It's currently forbidden to use `asm_goto` with output operands; that is still unstable under `asm_goto_with_outputs`. Example: ```rust unsafe { asm!( "jmp {}", label { println!("Jumped from asm!"); } ); } ``` Tests: - tests/ui/asm/x86_64/goto.rs - tests/ui/asm/x86_64/goto-block-safe.stderr - tests/ui/asm/x86_64/bad-options.rs - tests/codegen/asm/goto.rs
Rollup merge of rust-lang#133870 - nbdd0121:asm, r=traviscross,nnethercote Stabilize `asm_goto` feature gate Stabilize `asm_goto` feature (tracked by rust-lang#119364). The issue will remain open and be updated to track `asm_goto_with_outputs`. Reference PR: rust-lang/reference#1693 # Stabilization Report This feature adds a `label <block>` operand type to `asm!`. `<block>` must be a block expression with type unit or never. The address of the block is substituted and the assembly may jump to the block. When block completes the `asm!` block returns and continues execution. The block starts a new safety context and unsafe operations within must have additional `unsafe`s; the effect of `unsafe` that surrounds `asm!` block is cancelled. See rust-lang#119364 (comment) and rust-lang#131544. It's currently forbidden to use `asm_goto` with output operands; that is still unstable under `asm_goto_with_outputs`. Example: ```rust unsafe { asm!( "jmp {}", label { println!("Jumped from asm!"); } ); } ``` Tests: - tests/ui/asm/x86_64/goto.rs - tests/ui/asm/x86_64/goto-block-safe.stderr - tests/ui/asm/x86_64/bad-options.rs - tests/codegen/asm/goto.rs
Stabilize `asm_goto` feature gate Stabilize `asm_goto` feature (tracked by #119364). The issue will remain open and be updated to track `asm_goto_with_outputs`. Reference PR: rust-lang/reference#1693 # Stabilization Report This feature adds a `label <block>` operand type to `asm!`. `<block>` must be a block expression with type unit or never. The address of the block is substituted and the assembly may jump to the block. When block completes the `asm!` block returns and continues execution. The block starts a new safety context and unsafe operations within must have additional `unsafe`s; the effect of `unsafe` that surrounds `asm!` block is cancelled. See rust-lang/rust#119364 (comment) and rust-lang/rust#131544. It's currently forbidden to use `asm_goto` with output operands; that is still unstable under `asm_goto_with_outputs`. Example: ```rust unsafe { asm!( "jmp {}", label { println!("Jumped from asm!"); } ); } ``` Tests: - tests/ui/asm/x86_64/goto.rs - tests/ui/asm/x86_64/goto-block-safe.stderr - tests/ui/asm/x86_64/bad-options.rs - tests/codegen/asm/goto.rs
The asm-goto-with-outputs is still unstable, so in the reference it's still mentioned as forbidden by a check rule.
Stabilization PR: rust-lang/rust#133870