Tracking Issue for asm_sym

[Amanieu]

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

Summary

This feature adds a sym <path> operand type to asm! and global_asm!.

• <path> must refer to a fn or static.
• A mangled symbol name referring to the item is substituted into the asm template string.
• The substituted string does not include any modifiers (e.g. GOT, PLT, relocations, etc).
• <path> is allowed to point to a #[thread_local] static, in which case the asm code can combine the symbol with relocations (e.g. @plt, @TPOFF) to read from thread-local data.

Status

Blocked on support for sym in global_asm!.

[bstrie]

Is this note from #72016 still accurate?

The way sym is handled by the compiler (in HIR & typeck) is likely to change in the future to support it in global_asm. Currently it's a Path that's evaluated in the typeck context of the function containing the asm! but that doesn't work with global_asm! which exists outside of a function body.

[Amanieu]

Yes it is.

[dylanede]

Is there any chance of splitting stabilisation of this so that sym in asm! can be stabilised first, without waiting for global_asm! support?

[bstrie]

@dylanede Interesting, that seems like a reasonable idea. global_asm already forbids other operands, so it shouldn't even be much trouble to implement. And speaking personally, in our own codebase that would suffice to allow us to completely remove this feature gate.

[roblabla]

That was suggested during the stabilization of asm, but rejected because:

The current implementation of sym will likely need to be rewritten to support both asm! and global_asm!, which may cause subtle breaking changes (in particular with regards to functions with generic parameters).

[eddyb]

The way sym is handled by the compiler (in HIR & typeck) is likely to change in the future to support it in global_asm. Currently it's a Path that's evaluated in the typeck context of the function containing the asm! but that doesn't work with global_asm! which exists outside of a function body.

IMO the way to do this is to require an AnonConst (similar to the const {...} feature) around the sym path, at least in global_asm!. While it might be possible to whip up a typeck session without that, it seems easier to reuse the AnonConst functionality (similar to how we would implement typeof(...)).

Only downside I can think of is that it's a bit annoying that a HIR body containing a path to a static looks like it's reading from it (because static paths are place expressions instead of value expressions) - might be bypassed by "simply" not running actually running any MIR processing on it (including MIR borrowck), I'm not sure.

which may cause subtle breaking changes (in particular with regards to functions with generic parameters).

I would not want to disallow anything that works in paths within a function, seems like an artificial limitation when there is clearly an implementation strategy that works (i.e. the current one), and global_asm! is generally more limited anyway (making identical implementation between the two questionable).