- Feature Name:
- Start Date: 2019-12-31
- RFC PR: rust-lang/rfcs#2843
- Rust Issue: rust-lang/rust#70173
Deprecate the existing
asm! macro and provide an identical one called
llvm_asm!. The feature gate is also renamed from
llvm_asm! is not intended to ever become stable.
This change frees up the
asm! macro so that it can be used for the new
asm! macro designed by the inline asm project group while giving existing
asm! an easy way to keep their code working.
It may also be useful to have an inline asm implementation available
(on nightly) for architectures that the new
asm! macro does not support yet.
The Rust team is currently in the process of redesigning the
You should replace all uses of
llvm_asm! in your code to avoid breakage when the new
asm! macro is implemented.
All references to
asm! inside the compiler will be changed to refer to
asm! will become a simple (deprecated)
macro_rules! which redirects to
The deprecation warning will advise users that the semantics of
asm! will change in the future and invite them to use
llvm_asm! instead. The
llvm_asm! macro will be guarded by the
llvm_asm feature gate.
This change may require people to change their code twice: first to
llvm_asm!, and then to the new
asm! macro once it is implemented.
Rationale and alternatives
We could skip the deprecation period and perform the renaming at the same time the new
is implemented. However this is guaranteed to break a lot of code using nightly Rust at once without
any transition period.
The D programming language also support 2 forms of inline assembly. The first one provides an embedded DSL for inline assembly, which allows direct access to variables in scope and does not require the use of clobbers, but is only available on x86 and x86_64. The second one is a raw interface to LLVM's internal inline assembly syntax, which is available on all architectures but only on the LDC backend.
When the new
asm! macro is implemented it will replace the current one. This
will break anyone who has not yet transitioned their code to
silent miscompilations are expected since the operand separator will be changed
,, which will guarantee that any existing
asm! invocations will
fail with a syntax error with the new