-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
improve error message when global_asm!
uses asm!
options
#128207
Conversation
r? @Amanieu |
@bors r+ |
…r=Amanieu improve error message when `global_asm!` uses `asm!` options specifically, what was error: expected one of `)`, `att_syntax`, or `raw`, found `preserves_flags` --> $DIR/bad-options.rs:45:25 | LL | global_asm!("", options(preserves_flags)); | ^^^^^^^^^^^^^^^ expected one of `)`, `att_syntax`, or `raw` is now error: the `preserves_flags` option cannot be used with `global_asm!` --> $DIR/bad-options.rs:45:25 | LL | global_asm!("", options(preserves_flags)); | ^^^^^^^^^^^^^^^ the `preserves_flags` option is not meaningful for global-scoped inline assembly mirroring the phrasing of the [reference](https://doc.rust-lang.org/reference/inline-assembly.html#options). This is also a bit of a refactor for a future `naked_asm!` macro (for use in `#[naked]` functions). Currently this sort of error can come up when switching from inline to global asm, or when a user just isn't that experienced with assembly. With `naked_asm!` added to the mix hitting this error is more likely.
…iaskrgr Rollup of 3 pull requests Successful merges: - rust-lang#128006 (Make `missing_fragment_specifier` an error in edition 2024) - rust-lang#128207 (improve error message when `global_asm!` uses `asm!` options) - rust-lang#128266 (update `rust.channel` default value documentation) r? `@ghost` `@rustbot` modify labels: rollup
so CI fails on some of the aarch64 tests. I'm on x86, so how am I supposed to update those? for some using |
You can run the UI tests with a cross-compiler by running |
@@ -0,0 +1,10 @@ | |||
//@ run-rustfix |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This probably needs //@ needs-asm-support
otherwise it will fail on targets without asm support.
@bors r+ |
Rollup of 8 pull requests Successful merges: - rust-lang#125897 (from_ref, from_mut: clarify documentation) - rust-lang#128207 (improve error message when `global_asm!` uses `asm!` options) - rust-lang#128241 (Remove logic to suggest clone of function output) - rust-lang#128259 ([illumos/solaris] set MSG_NOSIGNAL while writing to sockets) - rust-lang#128262 (Delete `SimplifyArmIdentity` and `SimplifyBranchSame` tests) - rust-lang#128266 (update `rust.channel` default value documentation) - rust-lang#128267 (Add rustdoc GUI test to check title with and without search) - rust-lang#128271 (Disable jump threading of float equality) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#128207 - folkertdev:asm-parser-generalize, r=Amanieu improve error message when `global_asm!` uses `asm!` options specifically, what was error: expected one of `)`, `att_syntax`, or `raw`, found `preserves_flags` --> $DIR/bad-options.rs:45:25 | LL | global_asm!("", options(preserves_flags)); | ^^^^^^^^^^^^^^^ expected one of `)`, `att_syntax`, or `raw` is now error: the `preserves_flags` option cannot be used with `global_asm!` --> $DIR/bad-options.rs:45:25 | LL | global_asm!("", options(preserves_flags)); | ^^^^^^^^^^^^^^^ the `preserves_flags` option is not meaningful for global-scoped inline assembly mirroring the phrasing of the [reference](https://doc.rust-lang.org/reference/inline-assembly.html#options). This is also a bit of a refactor for a future `naked_asm!` macro (for use in `#[naked]` functions). Currently this sort of error can come up when switching from inline to global asm, or when a user just isn't that experienced with assembly. With `naked_asm!` added to the mix hitting this error is more likely.
…operand, r=Amanieu improve error message when `global_asm!` uses `asm!` operands follow-up to rust-lang#128207 what was ``` error: expected expression, found keyword `in` --> src/lib.rs:1:31 | 1 | core::arch::global_asm!("{}", in(reg)); | ^^ expected expression ``` becomes ``` error: the `in` operand cannot be used with `global_asm!` --> $DIR/parse-error.rs:150:19 | LL | global_asm!("{}", in(reg)); | ^^ the `in` operand is not meaningful for global-scoped inline assembly, remove it ``` the span of the error is just the keyword, which means that we can't create a machine-applicable suggestion here. The alternative would be to attempt to parse the full operand, but then if there are syntax errors in the operand those would be presented to the user, even though the parser already knows that the output won't be valid. Also that would require more complexity in the parser. So I think this is a nice improvement at very low cost.
…operand, r=Amanieu improve error message when `global_asm!` uses `asm!` operands follow-up to rust-lang#128207 what was ``` error: expected expression, found keyword `in` --> src/lib.rs:1:31 | 1 | core::arch::global_asm!("{}", in(reg)); | ^^ expected expression ``` becomes ``` error: the `in` operand cannot be used with `global_asm!` --> $DIR/parse-error.rs:150:19 | LL | global_asm!("{}", in(reg)); | ^^ the `in` operand is not meaningful for global-scoped inline assembly, remove it ``` the span of the error is just the keyword, which means that we can't create a machine-applicable suggestion here. The alternative would be to attempt to parse the full operand, but then if there are syntax errors in the operand those would be presented to the user, even though the parser already knows that the output won't be valid. Also that would require more complexity in the parser. So I think this is a nice improvement at very low cost.
Rollup merge of rust-lang#128305 - folkertdev:asm-parser-unsupported-operand, r=Amanieu improve error message when `global_asm!` uses `asm!` operands follow-up to rust-lang#128207 what was ``` error: expected expression, found keyword `in` --> src/lib.rs:1:31 | 1 | core::arch::global_asm!("{}", in(reg)); | ^^ expected expression ``` becomes ``` error: the `in` operand cannot be used with `global_asm!` --> $DIR/parse-error.rs:150:19 | LL | global_asm!("{}", in(reg)); | ^^ the `in` operand is not meaningful for global-scoped inline assembly, remove it ``` the span of the error is just the keyword, which means that we can't create a machine-applicable suggestion here. The alternative would be to attempt to parse the full operand, but then if there are syntax errors in the operand those would be presented to the user, even though the parser already knows that the output won't be valid. Also that would require more complexity in the parser. So I think this is a nice improvement at very low cost.
…r=Amanieu improve error message when `global_asm!` uses `asm!` operands follow-up to rust-lang/rust#128207 what was ``` error: expected expression, found keyword `in` --> src/lib.rs:1:31 | 1 | core::arch::global_asm!("{}", in(reg)); | ^^ expected expression ``` becomes ``` error: the `in` operand cannot be used with `global_asm!` --> $DIR/parse-error.rs:150:19 | LL | global_asm!("{}", in(reg)); | ^^ the `in` operand is not meaningful for global-scoped inline assembly, remove it ``` the span of the error is just the keyword, which means that we can't create a machine-applicable suggestion here. The alternative would be to attempt to parse the full operand, but then if there are syntax errors in the operand those would be presented to the user, even though the parser already knows that the output won't be valid. Also that would require more complexity in the parser. So I think this is a nice improvement at very low cost.
specifically, what was
is now
mirroring the phrasing of the reference.
This is also a bit of a refactor for a future
naked_asm!
macro (for use in#[naked]
functions). Currently this sort of error can come up when switching from inline to global asm, or when a user just isn't that experienced with assembly. Withnaked_asm!
added to the mix hitting this error is more likely.