Tracking Issue for inline assembly (`asm!`)

[Amanieu]

This is a tracking issue for the RFC 2873 (rust-lang/rfcs#2873).
The feature gate for the issue is #![feature(asm)].

Stabilization

• Blockers: Tracking Issue for inline assembly (asm!) #72016 (comment)
• Blockers: Tracking Issue for inline assembly (asm!) #72016 (comment)
• Stabilization report: Tracking Issue for inline assembly (asm!) #72016 (comment)

Steps

• Implement the RFC (Implement new asm! syntax from RFC 2850 #69171)
• LLVM version check (Implement new asm! syntax from RFC 2850 #69171 (comment), min-LLVM: Can only use x86 asm ATT syntax for LLVM < 10 in new asm! #76738)
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Implementation history

• Implement new asm! syntax from RFC 2850 #69171 Initial implementation

---

January status update

---

April status update

---

July status update

---

November stabilization report for FCP
November FCP checklist

[joshtriplett]

Note: if you'd like to report an issue in inline assembly, please report it as a separate github issue, and just link to this one. Please don't report issues in inline assembly as comments on this tracking issue.

[BartMassey]

Should the asm! macro be available directly from the prelude as it is now, or should it have to be imported from std::arch::$ARCH::asm? The advantage of the latter is that it would make it explicit that the asm! macro is target-specific, but it would make cross-platform code slightly longer to write.

Definitely want the explicit import. This would also make it a bit clearer what's going on when somebody tries to compile an old-style asm! with a newer compiler, which is going to happen a lot: you'd get an unresolved symbol rather than mysterious syntax errors.

[joshtriplett]

On Mon, May 25, 2020 at 03:56:53PM -0700, Bart Massey wrote: Definitely want the explicit import. This would also make it a bit clearer what's going on when somebody tries to compile an old-style `asm!` with a newer compiler, which is going to happen a lot: you'd get an unresolved symbol rather than mysterious syntax errors.

Rust will actually catch many instances of this. Any use of the old `asm!` syntax that has any operands at all will get caught in the parser (because it uses a ':'), and result in a very clear error telling the user about the syntax transition, and a hint suggesting `llvm_asm!`. (At some point that hint should also start suggesting the use of the new syntax.) The only case that wouldn't be caught in the parser would be if you have an `asm!` that has no inputs, no outputs, no clobbers, and no options, so it just looks like `asm!("...");`. In that case, on x86, it'll give you an assembly syntax error from the backend if you used AT&T syntax. We might, theoretically, be able to do a little better than *that*, as well; looking into that.

[petrochenkov]

Minor compatibility concern: asm! supports some LLVM-isms like C style comments /* comment */ (#73056 (comment)).

Other backends using external assemblers may need to do some pre-processing before passing the asm text to them.

[programmerjake]

Minor compatibility concern: asm! supports some LLVM-isms like C style comments /* comment */ (#73056 (comment)).

GNU Assembler (IIRC defined as the official assembly dialect by the RFC), and by extension GCC, supports C-style comments too, so they are definitely not LLVM-specific.

[newpavlov]

Namespacing the asm! macro

I am also in favor of explicit imports from arch modules. I would suggest going even further and introduce separate macros for each supported target (e.g. asm_x86!, asm_arm!, etc.).