in asm!() using a local numeric label made of all 0's and 1's gives a confusing error

[oconnor663]

rustc 1.59.0 (9d1b2106e 2022-02-23)

Here's a function that jumps to a local numberic label inside of asm!:

use std::arch::asm;

#[cfg(target_arch = "x86_64")]
fn main() {
    let mut counter: u64 = 0;
    unsafe {
        asm!(
            "2:",
            "inc {counter}",
            "cmp {counter}, 10",
            "jnz 2b",
            counter = inout(reg) counter,
        );
    }
    dbg!(counter);  // prints 10
}

As per Rust By Example, we use 2: as a local label there to work around an LLVM bug that mistakes labels like 0:, 1:, or 10: for binary. This example works. However, if we don't know about this rule, and we try to use 0: instead, the error we get is confusing:

error: invalid operand for instruction
  --> src/main.rs:11:14
   |
11 |             "jnz 0b",
   |              ^
   |
note: instantiated into assembly here
  --> <inline asm>:5:1
   |
5  | jnz 0b
   | ^

error: could not compile `scratch` due to previous error

Using 1: is the same:

error: invalid operand for instruction
  --> src/main.rs:11:14
   |
11 |             "jnz 1b",
   |              ^
   |
note: instantiated into assembly here
  --> <inline asm>:5:1
   |
5  | jnz 1b
   | ^

error: could not compile `scratch` due to previous error

It would be pretty great to have a hint here like "0: and 1: aren't valid local labels unfortunately, so just start with 2:".

[asquared31415]

@rustbot claim

[joshtriplett]

Documenting something that isn't explicitly stated here: this is an issue specifically related to the use of Intel syntax, because (AFAICT) LLVM doesn't have this issue for AT&T syntax.

This seems like something that, eventually, we could try to get a fix for into LLVM. We would need an assembly dialect option that either handles binary numbers differently or handles backwards labels differently.

[asquared31415]

While the diagnostics side of this is fixed and so this issue should remain closed, I think that the underlying bug that prevents these labels from being usable should be tracked somewhere, does anyone know if we already have an issue for that underlying bug?

[joshtriplett]

@asquared31415 I don't think we have an issue for that. We probably should, but ultimately I think we can't fix it without some upstream support in LLVM. (Assuming we continue to not attempt to parse all assembly ourselves.)