add `asm_cfg`: `#[cfg(...)]` within `asm!` #140367

folkertdev · 2025-04-27T14:11:54Z

tracking issue: #140364
blocked on: #140490

This feature was discussed in #140279. It allows configuring templates and operands in the assembly macros, for example:

asm!( // or global_asm! or naked_asm!
    "nop",
    #[cfg(target_feature = "sse2")]
    "nop",
    // ...
    #[cfg(target_feature = "sse2")]
    a = const 123, // only used on sse2
);

r? @tgross35

cc @traviscross @Amanieu

Now builds on #140490, which should be merged first.

folkertdev · 2025-04-27T14:14:12Z

compiler/rustc_builtin_macros/src/asm.rs

+        let is_configured_out =
+            ecx.ecfg.features.asm_cfg() && strip_unconfigured.configure(attributes).is_none();
+
+        let template = p.parse_expr()?;


The fact that we use parse_expr here mean that this does not work, and does not produce a great error message. This complains about an unexpected , after the 6, but the real problem is that this cannot possibly be or expand to a string literal.

asm!( #[cfg(false)] a = const 6, "nop", );

Maybe we should specialize the parser to specifically only parse string literals and item macros?

folkertdev · 2025-04-27T14:16:26Z

compiler/rustc_builtin_macros/src/asm.rs

    if p.token == token::Eof {
        return Err(dcx.create_err(errors::AsmRequiresTemplate { span: sp }));
    }

-    let first_template = p.parse_expr()?;
+    let first_template = loop {
+        let attributes = AsmAttrVec::parse(ecx, p)?;


attributes are now parsed before the parse_expr below, and never attached to the expression. In theory that could interact with #[feature(stmt_expr_attributes)], but:

that feature is unstable

any attributes it parsed would have no effect

folkertdev · 2025-04-27T14:17:44Z

compiler/rustc_builtin_macros/src/asm.rs

+                _ => {
+                    ecx.dcx().emit_err(errors::AsmAttributeNotSupported { span: attr.span() });
+                }


non-cfg attributes are now accepted by the parser, but emit this error. Previously attributes were only parsed (and later rejected, unless #[feature(stmt_expr_attributes)] was enabled) on expressions. We now also always parse them on operands.

folkertdev · 2025-04-27T14:47:18Z

Hmm, rust analyzer also parses the assembly, but from what I can see it has no way of evaluating the cfgs while parsing. Maybe that can change, but if not we'll have to fundamentally change the parser to just parse, and then later have a validation pass. I tried that before and it's possible but messy, and you need to store a lot more information in AsmArgs (that rust-analyzer then would also have to process).

@rust-lang/rust-analyzer how can we make this work?

ChayimFriedman2 · 2025-04-27T17:26:44Z

(I haven't looked at the PR, but) parsing does not evaluated cfgs. Hir lowering does.

folkertdev · 2025-04-27T17:57:04Z

Well in any case the parser doesn't. I'm not exactly sure where to draw the line for when HIR lowering starts, but certainly macro expansion of builtin macros is able to do it, e.g. here for cfg!:

rust/compiler/rustc_builtin_macros/src/cfg.rs

Lines 24 to 30 in 267cae5

    
           let matches_cfg = attr::cfg_matches( 
        
               &cfg, 
        
               &cx.sess, 
        
               cx.current_expansion.lint_node_id, 
        
               Some(cx.ecfg.features), 
        
           ); 
        
           MacEager::expr(cx.expr_bool(sp, matches_cfg))

Anyway, are you saying that rust-analyzer just cannot evaluate cfg's while parsing the asm! macro? We can delay it, but I think that just means that rust-analyzer would have to duplicate the logic.

Veykril · 2025-04-28T04:19:26Z

rust-analyzer has to duplicate these changes either way. We don't use any of the touched rustc crates here.

apparently it doesn't really use the asm parsing at present, so this may work?

folkertdev · 2025-04-30T10:45:09Z

I got confused between rust-analyzer and rustfmt here, sorry about that.

I've also opened #140490, which will make adding the cfg support a lot easier ( have that working on a branch). So for now:

@rustbot author

rustbot · 2025-04-30T10:45:13Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

tgross35 · 2025-05-02T04:51:55Z

I'm still take a look through this, but I don't know enough about this area of the compiler to give a good review. Picking somebody who shows up in the blame a lot:

r? @nnethercote

rustbot · 2025-05-02T13:44:09Z

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

traviscross

@rustbot author

traviscross · 2025-05-03T09:28:16Z

compiler/rustc_builtin_macros/src/asm.rs

+        loop {
+            if p.token != token::Pound {
+                break;
+            }


This can be phrased as while, no?

Yes, but I think this whole loop/function needs to change, to make the parsing of attributes consistent.

@nnethercote you seem to have worked on the attribute parsing a bit (and are the current reviewer here), what would be a good way to do this? e.g. this function is private, but I think it's what should be used here:

rust/compiler/rustc_parse/src/parser/attr.rs

Line 44 in 5fe04cb

pub(super) fn parse_outer_attributes(&mut self) -> PResult<'a, AttrWrapper> {

It returns an AttrWrapper which deliberately does not give access to the inner attributes until you call collect_tokens (another private function). Does it make sense to make those functions public, or should the asm attribute parsing live in rustc_parse instead?

after thinking about this some more, it might makes sense to, now that parsing and validation are split, to move the asm parsing code into rustc_parse?

traviscross · 2025-05-03T09:44:33Z

tests/ui/asm/cfg-parse-error.rs

+
+fn main() {
+    unsafe {
+        // Templates are not allowed after operands (even if the operands are configured out).


Is this a reasonable restriction? I'm thinking here about macros that might want to expand something like:

cfg_match! { one => { "jmp here", options(some_option), }; two => { "jmp there", options(other_option), }; }

Into:

#[cfg(one)] "jmp here", #[cfg(one)] options(some_option), #[cfg(and(not(one), two)] "jmp there", #[cfg(and(not(one), two)] options(other_option),

Hmm yeah that's a good point.

We'd have to make some further parser changes to make that work. Currently the parsing rules change based on whether a template has already been parsed (mostly for error message quality).

A second issue is that templates are currently parsed with the general expression parser, but some of the non-template arguments parse as valid expressions (e.g. options(noreturn) looks like a function call, and const { 5 } is also a valid expression).

A solution is to instead parse specifically string literals and macro calls, those are templates, and if those fail to parse, try to parse an operand.

traviscross · 2025-05-03T09:50:39Z

tests/ui/asm/cfg.rs

+//@ revisions: reva revb
+//@ only-x86_64
+//@ run-pass
+#![feature(asm_cfg, cfg_match)]


It'd be worth showing that cfg_match! works within asm!.

It really doesn't work right now. I believe there are some issues with using cfg_match! in expression position.

error: macro expansion ignores `#` and any tokens following --> /rustc/FAKE_PREFIX/library/core/src/macros/mod.rs:255:13 | ::: /home/folkertdev/rust/rust/tests/ui/asm/cfg.rs:84:9 | LL | / cfg_match! { LL | | reva => { "mov rax, 5" } LL | | revb => { "mov rax, 10" } LL | | }, | |_________- caused by the macro expansion here | = note: the usage of `cfg_match!` is likely invalid in expression context help: you might be missing a semicolon here --> /home/folkertdev/rust/rust/tests/ui/asm/cfg.rs:87:10 | LL | };, | +

Also using

cfg_match! { reva => "mov rax, 5", revb => "mov rax, 10", },

Makes macro expansion hit the recursion limit

Right now you have to write cfg_match! {{ .. }} for it to work in expression position (no longer requiring the double brackets is a stabilization blocker for cfg_match!).

I'm still struggling with getting this to work. I think this should work, but it expands to an Expr::Block, which is not a string, and hence rejected.

#[unsafe(naked)] extern "C" fn with_cfg_match() -> u64 { core::arch::naked_asm!( cfg_match!{{ unix => {"mov rax, 5"} _ => {"mov rax, 10"} }}, "ret", ) }

using this instead

cfg_match!{{ unix => "mov rax, 5", _ => "mov rax, 10", }},

does not parse,

error: expected identifier, found reserved identifier `_` --> src/main.rs:10:9 | 10 | / cfg_match!{{ 11 | | unix => "mov rax, 5", 12 | | _ => "mov rax, 10", 13 | | }}, | |__________^ expected identifier, found reserved identifier

So, am I still using this macro wrong?

cc @CAD97 @tgross35

rustbot assigned tgross35 Apr 27, 2025

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 Apr 27, 2025

folkertdev commented Apr 27, 2025

View reviewed changes

This comment has been minimized.

Sign in to view

folkertdev added 9 commits April 29, 2025 20:25

determine later whether an explicit reg was used

d3157c9

extract operand parser

408cfef

a new parser generating the exact same error messages

fbc7181

cleanup parse_clobber_abi

61a9db7

cleanup parse_options

e15b0f6

cleanup unused code

f39a13a

more cleanup

2860b75

leave a note about maybe delaying an error message

7935e87

attempt to have rustfmt use the new logic

d30124a

apparently it doesn't really use the asm parsing at present, so this may work?

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 30, 2025

rustbot assigned nnethercote and unassigned tgross35 May 2, 2025

folkertdev force-pushed the asm-cfg branch from 5cfd71a to feddf14 Compare May 2, 2025 13:44

folkertdev mentioned this pull request May 2, 2025

split asm! parsing and validation #140490

Open

This comment has been minimized.

Sign in to view

folkertdev force-pushed the asm-cfg branch from feddf14 to 4c15900 Compare May 2, 2025 14:18

This comment has been minimized.

Sign in to view

support #[cfg(...)] on arguments to the asm! macros

6cc60a6

folkertdev force-pushed the asm-cfg branch from 4c15900 to 6cc60a6 Compare May 2, 2025 14:47

traviscross reviewed May 3, 2025

View reviewed changes

traviscross mentioned this pull request May 6, 2025

Tracking issue for cfg_match #115585

Open

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add `asm_cfg`: `#[cfg(...)]` within `asm!` #140367

add `asm_cfg`: `#[cfg(...)]` within `asm!` #140367

folkertdev commented Apr 27, 2025 •

edited

Loading

folkertdev Apr 27, 2025

folkertdev Apr 27, 2025

folkertdev Apr 27, 2025

This comment has been minimized.

folkertdev commented Apr 27, 2025

ChayimFriedman2 commented Apr 27, 2025

folkertdev commented Apr 27, 2025

Veykril commented Apr 28, 2025

folkertdev commented Apr 30, 2025

rustbot commented Apr 30, 2025

tgross35 commented May 2, 2025

rustbot commented May 2, 2025

This comment has been minimized.

This comment has been minimized.

traviscross left a comment

traviscross May 3, 2025

folkertdev May 3, 2025

folkertdev May 3, 2025

traviscross May 3, 2025

folkertdev May 3, 2025

traviscross May 3, 2025

folkertdev May 3, 2025 •

edited

Loading

traviscross May 3, 2025 •

edited

Loading

folkertdev May 3, 2025

traviscross May 3, 2025

add asm_cfg: #[cfg(...)] within asm! #140367

Are you sure you want to change the base?

add asm_cfg: #[cfg(...)] within asm! #140367

Conversation

folkertdev commented Apr 27, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment has been minimized.

folkertdev commented Apr 27, 2025

ChayimFriedman2 commented Apr 27, 2025

folkertdev commented Apr 27, 2025

Veykril commented Apr 28, 2025

folkertdev commented Apr 30, 2025

rustbot commented Apr 30, 2025

tgross35 commented May 2, 2025

rustbot commented May 2, 2025

This comment has been minimized.

This comment has been minimized.

traviscross left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

folkertdev May 3, 2025 • edited Loading

Choose a reason for hiding this comment

traviscross May 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

add `asm_cfg`: `#[cfg(...)]` within `asm!` #140367

add `asm_cfg`: `#[cfg(...)]` within `asm!` #140367

folkertdev commented Apr 27, 2025 •

edited

Loading

folkertdev May 3, 2025 •

edited

Loading

traviscross May 3, 2025 •

edited

Loading