"avoid using named labels" mis-identifies inst operand as label

[androm3da]

Code

// In hexagon assembly syntax, register pairs are delimited with colons like `r17:16`.


pub unsafe fn hexagon_regpair_example() {
    asm!(
        // this instruction performs a double-word load to r1 and r0
        "r1:0 = memd(r29+#0)",
        lateout("r0") _, lateout("r1") _
    );
}

Current output

error: avoid using named labels in inline assembly
  --> src/lib.rs:23:10
   |
23 |         "r1:0 = memd(r29+#0)",
   |          ^^
   |

Desired output

<not an error - no diagnostic emitted>

Rationale and extra context

No response

Other cases

Rust Version

$ rustc --version
rustc 1.89.0-nightly (49a8ba068 2025-06-14)

Anything else?

If you have a pointer to other similar "narrowing the pattern matched for this diag" commit(s) I can make the change.

[workingjubilee]

@androm3da PRs like the one you might be thinking of making:

• Make named_asm_labels lint not trigger on unicode and trigger on format args #119195
• Don't lint against named labels in naked_asm! #140871

[asquared31415]

this lint is my horrible creation and every day i loathe it further 😭 it has some use, but really i think that the right way to go is just be very aggressive in documentation about "DONT DO THIS, IT MAY BREAK"

inherently, to accurately lint this, we have to be in the assembler, but by the time you're in the assembler, you've lost too much information to be able to create good diagnostics.

[androm3da]

inherently, to accurately lint this, we have to be in the assembler, but by the time you're in the assembler, you've lost too much information to be able to create good diagnostics.

Gee, maybe that's not that hard, really? What if we made a new directive pair that causes the assembler to emit a when (public) symbols are included in that region? Seems like this is the same problem faced by other languages like C, C++, right? Maybe Fortran and Zig inline asm has the same challenges?

[androm3da]

inherently, to accurately lint this, we have to be in the assembler, but by the time you're in the assembler, you've lost too much information to be able to create good diagnostics.

Gee, maybe that's not that hard, really? What if we made a new directive pair that causes the assembler to emit a when (public) symbols are included in that region? Seems like this is the same problem faced by other languages like C, C++, right? Maybe Fortran and Zig inline asm has the same challenges?

Ok so I gave it a whirl - llvm/llvm-project#146215 - maybe it'll be a suitable solution