`binary_asm_labels` should suggest a change

[tgross35]

Code

use std::arch::asm;

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

Current output

error: avoid using labels containing only the digits `0` and `1` in inline assembly
   --> src/aarch64_linux.rs:142:22
    |
142 |                     "0:",
    |                      ^ use a different label that doesn't start with `0` or `1`
...
271 | foreach_cas!(compare_and_swap);
    | ------------------------------ in this macro invocation
    |
    = note: an LLVM bug makes these labels ambiguous with a binary literal number
    = note: `#[deny(binary_asm_labels)]` on by default
    = note: this error originates in the macro `compare_and_swap` which comes from the expansion of the macro `foreach_cas` (in Nightly builds, run with -Z macro-backtrace for more info)

Desired output

Suggest a change that fixes this.

Rationale and extra context

I don't see any documentation about binary_asm_labels, so we should probably suggest what to do instead. I think the correct thing is to start numbering from 2.

The lint was added in #126922 (cc @asquared31415) to fix issue #94426.

Other cases

No response

Rust Version

1.81.0-nightly (24d2ac0b5 2024-07-15)

Anything else?

No response

[tgross35]

There also doesn't seem to be an issue filed either here or at LLVM for actually fixing this issue, at least not that I can find.

[tgross35]

Also, is this problem x86-specific? The lint is firing on aarch64.

[tgross35]

It indeed looks like this is an x86-only problem. Looks like compiler explorer won't objdump non-x86 files https://rust.godbolt.org/z/avoE4Gdfa but the sample builds and runs on my aarch64 machine.

[estebank]

@tgross35 can you follow another ticket for making this trigger not when it is compiled in an x86 platform but rather when it could be compiled in an x86 platform (because it is not behind an appropriate cfg flag)? Otherwise an hypothetical person writing generic code on ARM could ship code to their users that will have miscompilations, but because this is a lint, the users (and by extension, the authors) might never find out about the problem.

[tgross35]

Sure, #127938