Tracking Issue for asm_const

[Amanieu]

The feature gate for the issue is #![feature(asm_const)].

Summary

This feature adds a const <expr> operand type to asm! and global_asm!.

• <expr> must be an integer constant expression.
• The value of the expression is formatted as a string and substituted directly into the asm template string.

Status

~~Blocked on the stabilization of inline consts (#76001).~~

[bstrie]

Is it possible that this may not actually be blocked on inline_const? AIUI, the concern was that stabilizing asm_const would expose the semantics of inline_const to stable, so any change to the semantics of the yet-unstable inline_const would potentially break stable users of asm_const. But AFAICT there are no more foreseen semantic changes coming to inline_const, and the only remaining question is a syntactic one, specifically with regard to how macros would consume const {} blocks, which seems irrelevant to asm! which is providing its own syntax over inline_const anyway. Of course, it's worth asking to determine whether or not it's correct that the semantics of inline_const have truly solidified.

[tiagomanczak]

Any progress on this issue? We are working in a project were it is necessary, and the stabilization is important for future use in productive code. Any forms we can contribute to the stabilization of asm_const?

[nbdd0121]

asm_const is blocked on stabilisation of inline_const because it shares a lot of the same issue (e.g. post-mono errors)

[asquared31415]

#121099 is probably a blocker, a trivial to encounter ICE

[tgross35]

I think this should be unblocked since inline_const just merged https://github.com/rust-lang/rust/pull/104087. Could somebody update the top post with an example? I don't think we have use of this documented anywhere.

[luojia65]

I suggest we can push forward on stabilization, since inline_const has been stabilized a short period of time ago. Feature asm_const is useful on bare-metal development like system, kernel development, bootloader, firmware and embedded Rust etc.

[joshtriplett]

:+1: for pushing forwards with this. Could we get a brief stabilization report on the current state of this and whether there's any other blocker to stabilization? (Please tag this I-lang-nominated when that stabilization report is available.) I'm happy to start an FCP as soon as that happens.

[Amanieu]

Stabilization report

This feature adds a const <expr> operand type to asm! and global_asm!.

• <expr> must be an integer constant expression. This expression follows the same rules as inline const blocks.
• The type of the expression may be any integer type, but defaults to i32 just like integer literals.
• The value of the expression is formatted as a string and substituted directly into the asm template string.

[Lokathor]

@joshtriplett just a reminder ping to start an FCP, since the brief stabilization report was posted here

[joshtriplett]

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• [x] @joshtriplett
• [ ] @nikomatsakis
• [x] @pnkfelix
• [x] @scottmcm
• [x] @tmandry

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. See this document for info about what commands tagged team members can give me.

[rfcbot]

:bell: This is now entering its final comment period, as per the review above. :bell:

[tmandry]

We discussed this in today's lang meeting and I wanted to document the reasons for allowing const without braces here:

• The expression always goes to the next comma; there's no more complex expressions where you would want to have, e.g. const { FOO / 2 } - bar.
• It's consistent with other non-bracy things like inout.

An example:

    asm!(
        "mov {tmp}, {x}",
        "shl {tmp}, {one}",
        "shl {x}, {two}",
        "add {x}, {tmp}",
        x = inout(reg) x,
        tmp = out(reg) _,
        one = const 1,
        two = const 1 + 1,
        thing = in(reg) 2 * f(), // already valid. 
    );

Allowing arbitrary string substitution (including, e.g., in the middle of a label like jmp label_{my_const}) is interesting, but feels consistent since the syntax is shared by format strings, and seems like a natural extension of the substitution we already do for asm!.

@rfcbot reviewed

[RalfJung]

blocked on stabilisation of inline_const because it shares a lot of the same issue (e.g. post-mono errors)

So in MIR is this represented the same way, and added to required_consts like inline const?

[RalfJung]

Looks like yes these are normal consts:

https://github.com/rust-lang/rust/blob/e6b2b764ecf08e3144274383e8f95e51fcaa6963/compiler/rustc_middle/src/mir/visit.rs#L595-L601

[tgross35]

Is there any reason this couldn't eventually be extended to take strings rather than just integers? This would be nice for creating named functions.

const FN_NAME: &str = "foo";
const FN_IDX: u32 = 10;

// works
core::arch::global_asm!(
    ".global lab_{label}"
    "lab_{label}:",
    "ret",
    label = const FN_IDX
);

// does not work
core::arch::global_asm!("
    ".global lab_{label}"
    "lab_{label}:",
    "ret",
    label = const FN_NAME
);

[nbdd0121]

Good point. If we want to reserve the ability to do that in the future then we need to tweak type inference a bit to stop constraining const operand to integers,

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[Lokathor]

@nbdd0121 is that a change that would need to happen now before stabilization, or would it be part of a later update allowing const str support?

[Amanieu]

I have a draft PR up (#125558) but I'm hitting the same ICE as #96304 but with const operands.

[ehuss]

@Amanieu Can this be closed now?