stabilize asm_cfg

[folkertdev]

tracking issue: #140364
closes #140364

Request for Stabilization

Summary

The cfg_asm feature allows #[cfg(...)] and #[cfg_attr(...)] on the arguments of the assembly macros, for instance:

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

Semantics

Templates, operands, options and clobber_abi in the assembly macros (asm!, naked_asm! and global_asm!) can be annotated with #[cfg(...)] and #[cfg_attr(...)]. When the condition evaluates to true, the annotated argument has no effect, and is completely ignored when expanding the assembly macro.

Documentation

reference PR: forthcoming (though maybe none is needed?)

Tests

• tests/ui/asm/cfg.rs checks that cfg'd arguments where the condition evaluates to false have no effect
• tests/ui/asm/cfg-parse-error.rs checks the parsing rules (parsing effectively assumes that the cfg conditions are all true)

History

• Lang proposal: Allow #[cfg(...)] within asm! #140279
• add asm_cfg: #[cfg(...)] within asm! #140367

Resolved questions

how are other attributes handled

Other attributes are parsed, but explicitly rejected.

unresolved questions

operand before template

The current implementation expects at least one template string before any operands. In the example below, if the cfg condition evaluates to true, the assembly block is ill-formed. But even when it evaluates to false this block is rejected, because the parser still expects just a template (a template is parsed as an expression and then validated to ensure that it is or expands to a string literal).

Changing how this works is difficult.

// This is rejected because `a = out(reg) x` does not parse as an expresion.
asm!(
	#[cfg(false)]
	a = out(reg) x, //~ ERROR expected token: `,`
	"",
);

lint on positional arguments?

Adding a lint to warn on the definition or use of positional arguments being cfg'd out was discussed in #140279 (comment) and subsequent comments. Such a lint is not currently implemented, but that may not be a blocker based on the comments there.

r? @traviscross (I'm assuming you'll reassign as needed)

[rustbot]

compiler-builtins is developed in its own repository. If possible, consider making this change to rust-lang/compiler-builtins instead.

cc @tgross35