Transition path for existing users of asm!

[Amanieu]

There are basically two options for transitioning to the new asm syntax.

Option 1

We simply change the asm! macro to the new syntax. All users of asm! on nightly will have to fix their code to use the new syntax.

Pros:

• Only one such transition is needed.

Cons:

• This is a pretty severe breaking change.
• No transition path for users of asm! on architectures not supported by the new macro.

Option 2

Rename asm! to llvm_asm! and keep it around as perma-unstable. Mark asm! as deprecated until it is eventually replaced by the new syntax.

Pros:

• llvm_asm! is still available for unsupported architectures, and for experimenting with unsupported register constraints.
• Users have time to fix their code before it stops working.

Cons:

• This will require two transitions: one to rename to llvm_asm! and one to port to the new asm! syntax.
• Requires maintaining two separate inline assembly implementations in the compiler.

[bjorn3]

Requires maintaining two separate inline assembly implementations in the compiler.

One of which is just a few houndred lines of code.

[gnzlbg]

We could make the meaning of asm! feature-gate dependent.

For example, if feature(asm), we keep asm! "as is", and start warning on it on nightly.

Then, we add a new feature gate, e.g., inline_asm, and if feature(inline_asm), we give the asm! macro the new semantics.

At some point later on, we stabilize inline_asm, and maybe remove feature(asm) and the old semantics from nightly.

---

EDIT: this is orthogonal to adding a feature(llvm_asm) feature gate, and an llvm_asm! macro that allows users to migrate to the old semantics. We should do this as well, and the warning for using feature(asm) should say that people should migrate their code to inline_asm for stability, or if they only want to experiment on nightly and want llvm semantics then they should migrate to llvm_asm!.

[Lokathor]

I would favor Option 2. It's easy as an end user to understand that I can quickly get my code working again with a 5 character change, and then when I have time (and when the language is ready) I could spend additional time to transition to the new system and possibly even move the crate to working on Stable.

[mark-i-m]

Option 2.5

1. Add llvm_asm
2. Warn for a few cycles on nightly that asm will be renamed to llvm_asm.
3. When the new implementation is ready. Rename asm to lvm_asm and allow people to start using the new asm.