diff options
| author | Jubilee <46493976+workingjubilee@users.noreply.github.com> | 2024-07-12 13:47:05 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-07-12 13:47:05 -0700 |
| commit | fc0136e4f43246f371c3fc98091d73c654338b58 (patch) | |
| tree | fc147d0eb7068ee1920b2fb0337e31b803492239 /compiler/rustc_pattern_analysis/src | |
| parent | 5d56572f06eb55d4e270663e03649d5fed4258d2 (diff) | |
| parent | 87856c4461c29eb8c8ef7e3fb28ccfcbd41e4120 (diff) | |
| download | rust-fc0136e4f43246f371c3fc98091d73c654338b58.tar.gz rust-fc0136e4f43246f371c3fc98091d73c654338b58.zip | |
Rollup merge of #126922 - asquared31415:asm_binary_label, r=estebank
add lint for inline asm labels that look like binary
fixes #94426
Due to a bug/feature in LLVM, labels composed of only the digits `0` and `1` can sometimes be confused with binary literals, even if a binary literal would not be valid in that position.
This PR adds detection for such labels and also as a drive-by change, adds a note to cases such as `asm!(include_str!("file"))` that the label that it found came from an expansion of a macro, it wasn't found in the source code.
I expect this PR to upset some people that were using labels `0:` or `1:` without issue because they never hit the case where LLVM got it wrong, but adding a heuristic to the lint to prevent this is not feasible - it would involve writing a whole assembly parser for every target that we have assembly support for.
[zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202024-06-20/near/445870628)
r? ``@estebank``
Diffstat (limited to 'compiler/rustc_pattern_analysis/src')
0 files changed, 0 insertions, 0 deletions