add lint for inline asm labels that look like binary #126922

asquared31415 · 2024-06-24T22:46:03Z

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

r? @estebank

asquared31415 · 2024-06-24T22:49:53Z

cc @Amanieu

joshtriplett · 2024-06-25T19:22:50Z

This seems like a good starting point!

Eventually, I hope we can get LLVM to have a mode without this "feature", and then rust assembly should use that mode by default. But in the interim, we should warn people.

compiler/rustc_lint/src/builtin.rs

compiler/rustc_lint/messages.ftl

estebank · 2024-06-25T20:08:04Z

tests/ui/asm/named-asm-labels.stderr

+error: avoid using named labels in inline assembly
+  --> $DIR/named-asm-labels.rs:156:14
+   |
+LL |         asm!(include_str!("named-asm-labels.s"));
+   |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


Interesting case. We should have a mechanism to display the contents of include and include_str and point inside of those files when complaining. At the very least, we should say "on line X col Y in file foo.s". Not to address in this PR.

Agreed, I don't like the solution I came up with originally, but I opted not to change it for now, since that's a separate decision and complicates the implementation.

compiler/rustc_lint/messages.ftl

joshtriplett · 2024-06-26T14:10:36Z

On Tue, Jun 25, 2024 at 01:14:20PM -0700, Esteban Kuber wrote: +lint_invalid_asm_label_binary = avoid using labels containing only the digits 0 and 1 in inline assembly + .help = use a different number that has at least one digit 2 or greater I'm unsure with the current wording. We mean that it can be *any* value other than 0 or 1, right? ```suggestion .label = use number 2 or greater ```

No, if I understand correctly, the problem is that any label whose digits are only `0` and `1` can be confused with binary if written with the 'b' suffix. This comes up most often with `0` and `1`, but if you had a label `10` or `11` or `100` it would trigger the same bug. `10b` to GCC is a reference to "label 10 backwards"; `10b` to MASM/VC++/LLVM-in-intel-syntax-mode is `2` written in binary.

asquared31415 · 2024-06-26T18:38:13Z

This seems like a good starting point!

Eventually, I hope we can get LLVM to have a mode without this "feature", and then rust assembly should use that mode by default. But in the interim, we should warn people.

Somehow Clang does work around this. Perhaps something that it does with using AT&T syntax by default and making the user write .intel_syntax is meaningful? I don't know enough about how Clang uses inline assembly to be sure though. Agreed that ideally this lint does get downgraded to allow by default by fixing the issue, but I think it's important in the meantime to give people a better error.

estebank · 2024-06-26T18:51:48Z

tests/ui/asm/named-asm-labels.rs

+        //~^ ERROR avoid using named labels
+        //~^^ ERROR avoid using named labels
+        //~^^^ ERROR avoid using named labels
+        //~^^^^ ERROR avoid using named labels


For future reference, this can also be written as

Suggested change

//~^ ERROR avoid using named labels

//~^^ ERROR avoid using named labels

//~^^^ ERROR avoid using named labels

//~^^^^ ERROR avoid using named labels

//~^ ERROR avoid using named labels

//~| ERROR avoid using named labels

//~| ERROR avoid using named labels

//~| ERROR avoid using named labels

bors · 2024-06-30T23:18:57Z

☔ The latest upstream changes (presumably #127174) made this pull request unmergeable. Please resolve the merge conflicts.

estebank · 2024-07-03T17:30:31Z

Please rebase on top of a recent HEAD and squash your commits. r=me after that.

asquared31415 · 2024-07-09T01:27:02Z

I additionally implemented the requested change to make the suggestion a label on the span rather than a help.

estebank · 2024-07-12T17:02:11Z

@bors r+

bors · 2024-07-12T17:02:13Z

📌 Commit 87856c4 has been approved by estebank

It is now in the queue for this repository.

…estebank add lint for inline asm labels that look like binary fixes rust-lang#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`

…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#126502 (Ignore allocation bytes in some mir-opt tests) - rust-lang#126606 (Guard against calling `libc::exit` multiple times on Linux.) - rust-lang#126922 (add lint for inline asm labels that look like binary) - rust-lang#127295 (CFI: Support provided methods on traits) - rust-lang#127310 (Fix import suggestion ice) - rust-lang#127535 (Fire unsafe_code lint on unsafe extern blocks) - rust-lang#127631 (Remove `fully_normalize`) - rust-lang#127632 (Implement `precise_capturing` support for rustdoc) r? `@ghost` `@rustbot` modify labels: rollup

…kingjubilee Rollup of 11 pull requests Successful merges: - rust-lang#126502 (Ignore allocation bytes in some mir-opt tests) - rust-lang#126922 (add lint for inline asm labels that look like binary) - rust-lang#127209 (Added the `xop` target-feature and the `xop_target_feature` feature gate) - rust-lang#127310 (Fix import suggestion ice) - rust-lang#127338 (Migrate `extra-filename-with-temp-outputs` and `issue-85019-moved-src-dir` `run-make` tests to rmake) - rust-lang#127381 (Migrate `issue-83045`, `rustc-macro-dep-files` and `env-dep-info` `run-make` tests to rmake) - rust-lang#127535 (Fire unsafe_code lint on unsafe extern blocks) - rust-lang#127619 (Suggest using precise capturing for hidden type that captures region) - rust-lang#127631 (Remove `fully_normalize`) - rust-lang#127632 (Implement `precise_capturing` support for rustdoc) - rust-lang#127660 (Rename the internal `const_strlen` to just `strlen`) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#126922 - asquared31415:asm_binary_label, r=estebank add lint for inline asm labels that look like binary fixes rust-lang#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``

In <rust-lang#126922>, the `binary_asm_labels` lint was added which flags labels such as `0:` and `1:`. Before that change, LLVM was giving a confusing error on x86/x86_64 because of an incorrect interpretation. However, targets other than x86 and x86_64 never had the error message and have not been a problem. This means that the lint was causing code that previously worked to start failing (e.g. `compiler_builtins`), rather than only providing a more clear messages where there has always been an error. Adjust the lint to only fire on x86 and x86_64 assembly to avoid this regression.

…y, r=estebank Change `binary_asm_labels` to only fire on x86 and x86_64 In <rust-lang#126922>, the `binary_asm_labels` lint was added which flags labels such as `0:` and `1:`. Before that change, LLVM was giving a confusing error on x86/x86_64 because of an incorrect interpretation. However, targets other than x86 and x86_64 never had the error message and have not been a problem. This means that the lint was causing code that previously worked to start failing (e.g. `compiler_builtins`), rather than only providing a more clear messages where there has always been an error. Adjust the lint to only fire on x86 and x86_64 assembly to avoid this regression. Also update the help message. Fixes: rust-lang#127821

…y, r=estebank,Urgau Change `binary_asm_labels` to only fire on x86 and x86_64 In <rust-lang#126922>, the `binary_asm_labels` lint was added which flags labels such as `0:` and `1:`. Before that change, LLVM was giving a confusing error on x86/x86_64 because of an incorrect interpretation. However, targets other than x86 and x86_64 never had the error message and have not been a problem. This means that the lint was causing code that previously worked to start failing (e.g. `compiler_builtins`), rather than only providing a more clear messages where there has always been an error. Adjust the lint to only fire on x86 and x86_64 assembly to avoid this regression. Also update the help message. Fixes: rust-lang#127821

Rollup merge of rust-lang#127935 - tgross35:binary_asm_labels-x86-only, r=estebank,Urgau Change `binary_asm_labels` to only fire on x86 and x86_64 In <rust-lang#126922>, the `binary_asm_labels` lint was added which flags labels such as `0:` and `1:`. Before that change, LLVM was giving a confusing error on x86/x86_64 because of an incorrect interpretation. However, targets other than x86 and x86_64 never had the error message and have not been a problem. This means that the lint was causing code that previously worked to start failing (e.g. `compiler_builtins`), rather than only providing a more clear messages where there has always been an error. Adjust the lint to only fire on x86 and x86_64 assembly to avoid this regression. Also update the help message. Fixes: rust-lang#127821

rustbot assigned estebank Jun 24, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 24, 2024

estebank reviewed Jun 25, 2024

View reviewed changes

This comment has been minimized.

Sign in to view

estebank reviewed Jun 26, 2024

View reviewed changes

This comment has been minimized.

Sign in to view

add lint for inline asm labels that look like binary

87856c4

rust-cloud-vms bot force-pushed the asm_binary_label branch from 4e0eeea to 87856c4 Compare July 9, 2024 01:24

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 12, 2024

matthiaskrgr mentioned this pull request Jul 12, 2024

Rollup of 8 pull requests #127657

Closed

workingjubilee mentioned this pull request Jul 12, 2024

Rollup of 11 pull requests #127665

Merged

bors merged commit fc0136e into rust-lang:master Jul 13, 2024
6 checks passed

rustbot added this to the 1.81.0 milestone Jul 13, 2024

tgross35 mentioned this pull request Jul 16, 2024

binary_asm_labels should suggest a change #127821

Closed

This was referenced Jul 18, 2024

Change binary_asm_labels to only fire on x86 and x86_64 #127935

Merged

Remove binary_asm_labels once the LLVM issue is fixed #127937

Open

workingjubilee mentioned this pull request Aug 4, 2024

Incorrect reporting of asm labels in Nightly #128659

Open

workingjubilee added the L-binary_asm_labels Lint: LLVM parses labels like 0, 1, 10, 11, etc. oddly label Aug 4, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add lint for inline asm labels that look like binary #126922

add lint for inline asm labels that look like binary #126922

asquared31415 commented Jun 24, 2024 •

edited by apiraino

Loading

asquared31415 commented Jun 24, 2024

joshtriplett commented Jun 25, 2024

estebank Jun 25, 2024

asquared31415 Jun 26, 2024

joshtriplett commented Jun 26, 2024 via email

asquared31415 commented Jun 26, 2024

This comment has been minimized.

estebank Jun 26, 2024

This comment has been minimized.

bors commented Jun 30, 2024

estebank commented Jul 3, 2024

asquared31415 commented Jul 9, 2024

estebank commented Jul 12, 2024

bors commented Jul 12, 2024

add lint for inline asm labels that look like binary #126922

add lint for inline asm labels that look like binary #126922

Conversation

asquared31415 commented Jun 24, 2024 • edited by apiraino Loading

asquared31415 commented Jun 24, 2024

joshtriplett commented Jun 25, 2024

estebank Jun 25, 2024

Choose a reason for hiding this comment

asquared31415 Jun 26, 2024

Choose a reason for hiding this comment

joshtriplett commented Jun 26, 2024 via email

asquared31415 commented Jun 26, 2024

This comment has been minimized.

estebank Jun 26, 2024

Choose a reason for hiding this comment

This comment has been minimized.

bors commented Jun 30, 2024

estebank commented Jul 3, 2024

asquared31415 commented Jul 9, 2024

estebank commented Jul 12, 2024

bors commented Jul 12, 2024

asquared31415 commented Jun 24, 2024 •

edited by apiraino

Loading