Skip to content

Conversation

@folkertdev
Copy link
Contributor

@folkertdev folkertdev commented Oct 24, 2025

Reference PR for:

@rustbot rustbot added the S-waiting-on-review Status: The marked PR is awaiting review from a maintainer label Oct 24, 2025
* [Function][functions], [closure] and [function pointer]
parameters accept outer attributes. This includes attributes on variadic parameters
denoted with `...` in function pointers and [external blocks][variadic functions].
* [Inline assembly] template strings and operands accept outer attributes.
Copy link
Contributor

@petrochenkov petrochenkov Oct 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, it may be a mostly theoretical concern, but attributes are not supported here.
asm! rather have an attribute-like syntax in its DSL - rust-lang/rust#147736 (comment).

The "only cfg and cfg_attr" restriction is unique to all attribute positions and is a direct consequence of the above.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This list is about allowed positions, and with asm_cfg attributes are parsed on template strings and operands, so saying that they are a valid position for attributes feels right.

But yeah they aren't really supported like in the other places listed here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an interesting question because for example in things like #1890 we document that diagnostics are allowed in all attribute positions. I'm not sure how to resolve that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there any diagnostics that are meaningful on a (macro call that expands to a) template string? We could parse and then silently discard them, but actually making the diagnostic attribute do something would be tough I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#[rustfmt::skip] could be meaningful, but assembly is not formatted at all currently, so in practice it won't do anything today.

Copy link
Contributor

@ehuss ehuss Oct 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know. You could have something silly like asm!(#[allow(named_asm_labels)] "warned: nop");, but I don't think that is something worth doing.

I'm not suggesting that it is something that should be changed. I'm just trying to think of how we can cleanly fit it in to the reference text.

@folkertdev folkertdev force-pushed the asm-cfg branch 4 times, most recently from 8fc2f56 to 58e0705 Compare October 25, 2025 14:29
@ehuss ehuss added the S-waiting-on-stabilization Waiting for a stabilization PR to be merged in the main Rust repository label Oct 30, 2025

r[asm.attributes.supported-attributes]
Only the [`cfg`] and [`cfg_attr`] attributes are accepted semantically on inline assembly template strings and operands. Other attributes are parsed, but rejected when the assembly macro is expanded.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add an example here showing cfg being used?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added

core::arch::naked_asm!(
    #[cfg(not(panic = "abort"))]
    ".cfi_startproc",
    // ...
    "ret",
    #[cfg(not(panic = "abort"))]
    ".cfi_endproc",
);

Loosely based on https://github.com/nbdd0121/unwinding/blob/3bc28cec6c30eade0e1caa094b49db78101b19ef/src/unwinder/arch/aarch64.rs#L66C24-L66C40.

It's tough to come up with simple full examples, so hopefully this conveys the idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: The marked PR is awaiting review from a maintainer S-waiting-on-stabilization Waiting for a stabilization PR to be merged in the main Rust repository

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants