Tracking Issue for asm_goto

[nbdd0121]

The feature gate for the issue is #![feature(asm_goto)].

Summary

This feature adds a label<block> operand type to asm!.

Example:

unsafe {
    asm!(
        "jmp {}",
        label {
            println!("Jumped from asm!");
        }
    );
}

The block must have unit type.

Steps

• Implementation
• Adjust documentation (see instructions on rustc-dev-guide)
• Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• LLVM miscompilation for asm goto with outputs asm goto miscompilation llvm/llvm-project#74483

@rustbot labels: +A-inline-assembly +F-asm

[Noratrieb]

Where is this coming from? Is there a lang MCP or anything like that?

[nbdd0121]

This is outlined as a future possibility in RFC2873 which I am implementing in #119365.

[tgross35]

Could we support a named label rather than being only positional? Maybe

unsafe { asm!(
    "jmp {foo}",
    label foo {
        println!("Jumped from asm!");
    }
);}

(I mean that foo would be the alias for use in the format string, not that the label in assembly would wind up as foo:)

[bjorn3]

unsafe { asm!(
    "jmp {foo}",
    foo = label {
        println!("Jumped from asm!");
    }
);}

is closer to the syntax used by other operands.

[tgross35]

oh, that does actually work already. Awesome

[joshtriplett]

In today's Rust-for-Linux meeting, we discussed this syntax. We realized a potential issue that wasn't considered during the design:

Because asm! always has to be in an unsafe block, that makes all the code in the labels be unsafe, too. That isn't necessarily what people want. If this integrated with existing if conditions people might write if unsafe { asm!(...) } { ... } else { ... } and those branches wouldn't be unsafe, but doing that with the current construct requires returning a bool (which currently requires label-break-value) and using that in an if, and hoping the optimizer does the right thing to have the asm branches go to the if branches. When we considered the label-based design as a syntactically simpler construct, we didn't consider that that would make the label blocks unsafe code.

We talked about a few possible ways to solve this. One that seemed appealing in the RfL meeting:

We could change the label blocks to be safe code by default. (There's some precedent for switching back to safe in unsafe code: if you define an item in an unsafe block, the contents of the item are safe.)

And, to make it less painful to use unsafe if you do need it, we can syntactically allow ident = label unsafe { /* unsafe code */ } in addition to ident = label { /* safe code */ }.

[Lokathor]

Do you mean a proposed future different extension to asm!, separate from asm_goto, would make asm! in some cases be an expression that could evaluate to a boolean? Because currently it can't be used in if like that so I'm a little confused.

[programmerjake]

We could change the label blocks to be safe code by default. (There's some precedent for switching back to safe in unsafe code: if you define an item in an unsafe block, the contents of the item are safe.)

I think we also need a more general safe { ... } block, since this is far from the only case where you want known-safe code inside an unsafe block, e.g. macros that expand to code like unsafe { unsafe_macro_helper(safe { safe_user_code() }, ...) }

[joshtriplett]

Do you mean a proposed future different extension to asm!, separate from asm_goto, would make asm! in some cases be an expression that could evaluate to a boolean? Because currently it can't be used in if like that so I'm a little confused.

When I said:

returning a bool (which currently requires label-break-value)

I mean this:

{'bar: { asm!("...", foo = label { break 'bar true; }); false }}