Lang proposal: Allow `#[cfg(...)]` within `asm!`

[tgross35]

Background

Currently there isn't an easy way to enable or disable portions of assembly based on configuration. This can be a annoyance for asm! that can be worked around with multiple assembly blocks, but it is especially a problem in global_asm! and naked_asm! because small config-based changes mean the entire assembly block needs to be duplicated.

Another workaround is possible by defining multiple macro_rules! of the same name that are enabled/disabled based on the desired config and expand to strings. This option is inconvenient and fragments the assembly.

Proposal

Allow #[cfg(...)] in all assembly macros:

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

The configuration applies to a single comma-separated segment.

We may want to also support blocks in order to allow grouping instructions without merging strings, or grouping directives:

asm!(
    "nop",
    #[cfg(target_feature = "sse2")] {
        "nop",
        "nop",
        "nop",
    } // does allowing/requiring a comma here make sense?
    "nop",
    #[cfg(target_feature = "sse2")] {
        a = const 123,
        a = const 123,
    }
);

This design has some concerns and there may be a better option, see discussion in the thread.

Zulip discussion: #project-inline-asm > `cfg` in assembly blocks

[tgross35]

Unfortunately I won't have the chance to work on this (at least for a while), but this been mentioned in a few different places so I wrote this up to keep track.

I'll probably add help wanted labels in case somebody interested wants to pick this up before I do, but @rust-lang/lang would anybody mind giving this a vibe check first? I'll nominate as well, feel free to remove if that doesn't make sense.

@rustbot label +I-lang-nominated +I-lang-easy-decision

[tgross35]

Cc @folkertdev in case you have any thoughts here, since you have done a lot of work on assembly internals recently.

[joshtriplett]

General thoughts: I like the concept, and it seems reasonable, but it also seems likely to become very verbose and redundant if you have many lines tagged with the same complex cfg. In C you can wrap multiple lines in the same ifdef, and I think this proposed syntax for cfg in asm! will lead people to combine multiple assembly lines into one string (e.g. with \n or with dialect-specific separators like ;), just to be able to use one cfg.

I'm wondering if we should proactively address that use case, to avoid encouraging suboptimal formatting like that.

For instance, perhaps we should allow:

asm!(
    "always",
    #[cfg(complicated)]
    {
        "sometimes",
        "perhaps",
    }
);

Also, ideally cfg_match! should work, to avoid having to write both cfg(complicated) and cfg(not(complicated)) (where complicated here is a stand-in for some very long compound cfg).

[tgross35]

I mentioned blocks on the Zulip thread as well, and think they would be a nice to have because it also allows applying the same cfg to multiple operands. Updated the description to include this.

@adamgreig linked to an example at https://github.com/rust-embedded/cortex-m/blob/c3d664bba1148cc2d0f963ebeb788aa347ba81f7/cortex-m-rt/src/lib.rs#L528-L636 that uses merged strings and looks pretty good, for comparison.

One downside of blocks is that we don't have any cases (that I can think of) where {...} can be used to group a subset of comma-delimited items within a larger list, like

let x = [1, 2, #[cfg(unix)] { 3, 4 }, 5];

Which may make cfg_match support more difficult. Agreed that this would great to have though (cfg_if as well).

Unfortunately with grouping, this got less easy :)

@rustbot label -I-lang-easy-decision

(looks like I'm racing with rustbot on the labels)