-
Notifications
You must be signed in to change notification settings - Fork 926
Add formatting support for the asm!
macro
#6526
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
Comments
rustfmt has never had dedicated support for the It's still an open ended question on how the |
Looks like no progress for the last 3 years then? And there is no real process that would make sure a decision is eventually made? Also, while maybe it's not been decided exactly what the formatting should look like, it is more functional for certain syntax components that are older, e.g. this unsafe fn foobar() {
core::arch::asm!("{}",
options(noreturn))
} does format to the expected unsafe fn foobar() {
core::arch::asm!("{}", options(noreturn))
} It would be nice if |
That's because There's no way around that until we add dedicated support for the |
asm!
operands const
and sym
are not formattedasm!
macro
Marking this as blocked on rust-lang/style-team#152 |
…manieu,traviscross split `asm!` parsing and validation This PR splits `asm!` parsing and validation into two separate steps. The parser constructs a `Vec<RawAsmArg>`, with each element corresponding to an argument to one of the `asm!` macros. The validation then checks things like ordering of arguments or that options are not provided twice. The motivation is rust-lang#140279, which wants to add `#[cfg(...)]` support to these arguments. This support can now be added in a straightforward way by adding an `attributes: ast::AttrVec` field to `RawAsmArg`. An extra reason for this split is that `rustfmt` probably wants to format the assembly at some point (currently that appears to be stubbed out, and the formatting is unstable rust-lang/style-team#152). r? `@ghost` (just want to look at CI for now) cc `@ytmimi` we discussed asm formatting a little while ago in rust-lang/rustfmt#6526. Am I correct in assuming that `AsmArgs` does not give enough information for formatting, but that `RawAsmArgs` would (it e.g. does not join information from multiple lines). This must have been an issue before?
…manieu,traviscross split `asm!` parsing and validation This PR splits `asm!` parsing and validation into two separate steps. The parser constructs a `Vec<RawAsmArg>`, with each element corresponding to an argument to one of the `asm!` macros. The validation then checks things like ordering of arguments or that options are not provided twice. The motivation is rust-lang#140279, which wants to add `#[cfg(...)]` support to these arguments. This support can now be added in a straightforward way by adding an `attributes: ast::AttrVec` field to `RawAsmArg`. An extra reason for this split is that `rustfmt` probably wants to format the assembly at some point (currently that appears to be stubbed out, and the formatting is unstable rust-lang/style-team#152). r? ``@ghost`` (just want to look at CI for now) cc ``@ytmimi`` we discussed asm formatting a little while ago in rust-lang/rustfmt#6526. Am I correct in assuming that `AsmArgs` does not give enough information for formatting, but that `RawAsmArgs` would (it e.g. does not join information from multiple lines). This must have been an issue before?
split `asm!` parsing and validation This PR splits `asm!` parsing and validation into two separate steps. The parser constructs a `Vec<RawAsmArg>`, with each element corresponding to an argument to one of the `asm!` macros. The validation then checks things like ordering of arguments or that options are not provided twice. The motivation is rust-lang#140279, which wants to add `#[cfg(...)]` support to these arguments. This support can now be added in a straightforward way by adding an `attributes: ast::AttrVec` field to `RawAsmArg`. An extra reason for this split is that `rustfmt` probably wants to format the assembly at some point (currently that appears to be stubbed out, and the formatting is unstable rust-lang/style-team#152). r? `@ghost` (just want to look at CI for now) cc `@ytmimi` we discussed asm formatting a little while ago in rust-lang/rustfmt#6526. Am I correct in assuming that `AsmArgs` does not give enough information for formatting, but that `RawAsmArgs` would (it e.g. does not join information from multiple lines). This must have been an issue before? try-job: aarch64-apple
…manieu,traviscross split `asm!` parsing and validation This PR splits `asm!` parsing and validation into two separate steps. The parser constructs a `Vec<RawAsmArg>`, with each element corresponding to an argument to one of the `asm!` macros. The validation then checks things like ordering of arguments or that options are not provided twice. The motivation is rust-lang#140279, which wants to add `#[cfg(...)]` support to these arguments. This support can now be added in a straightforward way by adding an `attributes: ast::AttrVec` field to `RawAsmArg`. An extra reason for this split is that `rustfmt` probably wants to format the assembly at some point (currently that appears to be stubbed out, and the formatting is unstable rust-lang/style-team#152). r? `@ghost` (just want to look at CI for now) cc `@ytmimi` we discussed asm formatting a little while ago in rust-lang/rustfmt#6526. Am I correct in assuming that `AsmArgs` does not give enough information for formatting, but that `RawAsmArgs` would (it e.g. does not join information from multiple lines). This must have been an issue before? try-job: aarch64-apple
…manieu,traviscross split `asm!` parsing and validation This PR splits `asm!` parsing and validation into two separate steps. The parser constructs a `Vec<RawAsmArg>`, with each element corresponding to an argument to one of the `asm!` macros. The validation then checks things like ordering of arguments or that options are not provided twice. The motivation is rust-lang#140279, which wants to add `#[cfg(...)]` support to these arguments. This support can now be added in a straightforward way by adding an `attributes: ast::AttrVec` field to `RawAsmArg`. An extra reason for this split is that `rustfmt` probably wants to format the assembly at some point (currently that appears to be stubbed out, and the formatting is unstable rust-lang/style-team#152). r? ``@ghost`` (just want to look at CI for now) cc ``@ytmimi`` we discussed asm formatting a little while ago in rust-lang/rustfmt#6526. Am I correct in assuming that `AsmArgs` does not give enough information for formatting, but that `RawAsmArgs` would (it e.g. does not join information from multiple lines). This must have been an issue before? try-job: aarch64-apple
Rollup merge of rust-lang#140490 - folkertdev:asm-parser-changes, r=Amanieu,traviscross split `asm!` parsing and validation This PR splits `asm!` parsing and validation into two separate steps. The parser constructs a `Vec<RawAsmArg>`, with each element corresponding to an argument to one of the `asm!` macros. The validation then checks things like ordering of arguments or that options are not provided twice. The motivation is rust-lang#140279, which wants to add `#[cfg(...)]` support to these arguments. This support can now be added in a straightforward way by adding an `attributes: ast::AttrVec` field to `RawAsmArg`. An extra reason for this split is that `rustfmt` probably wants to format the assembly at some point (currently that appears to be stubbed out, and the formatting is unstable rust-lang/style-team#152). r? ``@ghost`` (just want to look at CI for now) cc ``@ytmimi`` we discussed asm formatting a little while ago in rust-lang/rustfmt#6526. Am I correct in assuming that `AsmArgs` does not give enough information for formatting, but that `RawAsmArgs` would (it e.g. does not join information from multiple lines). This must have been an issue before? try-job: aarch64-apple
…aviscross split `asm!` parsing and validation This PR splits `asm!` parsing and validation into two separate steps. The parser constructs a `Vec<RawAsmArg>`, with each element corresponding to an argument to one of the `asm!` macros. The validation then checks things like ordering of arguments or that options are not provided twice. The motivation is rust-lang/rust#140279, which wants to add `#[cfg(...)]` support to these arguments. This support can now be added in a straightforward way by adding an `attributes: ast::AttrVec` field to `RawAsmArg`. An extra reason for this split is that `rustfmt` probably wants to format the assembly at some point (currently that appears to be stubbed out, and the formatting is unstable rust-lang/style-team#152). r? ``@ghost`` (just want to look at CI for now) cc ``@ytmimi`` we discussed asm formatting a little while ago in rust-lang/rustfmt#6526. Am I correct in assuming that `AsmArgs` does not give enough information for formatting, but that `RawAsmArgs` would (it e.g. does not join information from multiple lines). This must have been an issue before? try-job: aarch64-apple
Given a snippet like this
I'd expect that to format to
but instead nothing happens. Given that these operands are quite new, I suspect this is an oversight.
I'd happily look into fixing this, but I'm not 100% clear on whether the formatting behavior for existing code can be change? Though here I'd clearly consider it a bug.
The text was updated successfully, but these errors were encountered: