Decide whether `asm!` and/or `global_asm!` should be exported from the prelude.

[bstrie]

In #84019 it was decided that asm! and global_asm! should be defined in core::arch rather than be defined in the crate root. Whereas anything defined in the crate root is essentially "in the prelude" by necessity, being defined elsewhere means that we have the option of deciding whether or not these macros should be exported from the prelude.

In the original Zulip thread regarding which module these macros should be defined in, there was a small amount of discussion as to whether or not these should additionally be exported from the prelude: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/namespacing.20.60asm!.60/near/233407632 . There did not seem to be a clear prevailing opinion.

Furthermore, I faintly recall from the most recent libs-api meeting someone mentioning that adding new macros to the prelude (or even the crate root) might be a compatibility hazard, and should only be done during an edition. I'm not sure if this is an official policy or not.

Note that this is not a blocker for asm! stabilization, as the item can be stabilized at arch::asm and exported from the prelude any time in the future.

[m-ou-se]

The prelude should probably just contain things that are widely used. While asm!() has a pretty clear meaning, there's not going to be a lot of users.

However, @dtolnay mentioned that it might be good to have it in the prelude as a 'marketing' feature: People looking through the prelude documentation will discover the existence of inline assembly, showing that Rust is also a low level language.

On nightly, they're already in the prelude and seemingly not breaking anything, so that's not much of a concern.

Pinging @rust-lang/libs-api for more opinions.

[BurntSushi]

For me personally, it feels a little weird to put it in the prelude, especially if it's really just for marketing purposes. Inline assembly is a rarely used feature, so tucking it away into a module feels like the right thing to me.

Of course, making it easy to discover features is important too. My hope is that after inline assembly lands, doing a web search for "rust inline assembly" will (eventually) bring you to the right place. Maybe that's good enough?

[joshtriplett]

"marketing" is an interesting angle I hadn't considered.

Personally, I think these should be in the prelude for a different reason: to make them feel like innate language capabilities. You don't have to import a name from a module to use things like async and await, or closures, or (in the future) generators. I think inline assembly should feel the same way.

[thomcc]

My gut feeling is that inline assembly uses macro syntax might mean that it won't feel like an innate language capability even if it is in the prelude.

I think putting it in a module¹ is the right balance given how rarely it's used, and I say this as someone who uses it frequently, even in its current unstable state.

1: Well, fine so long as it's not a different module for each arch, which I believe is no longer being considered.

[Amanieu]

I feel ambivalent about this: I am probably one of the bigger users of asm! (78 uses over 10 files), but adding an import line for this is really very little effort that I don't mind it. In the end, I am happy with both options.

[npmccallum]

I'm a pretty big user of this (at least a few dozen invocations across a bunch of crates). I also don't mind an import line. I suspect that use of this feature is somewhat uncommon and I'd hate to litter the prelude for my minor inconvenience. Anyone who needs this feature knows they need it and can google it. I don't see a reason to advertise it.

I use TryFrom a lot more and it isn't (yet) in the prelude (this one does bug me...).

[thomcc]

adding an import line for this is really very little effort that I don't mind it.

Ultimately, the fact that you'll be able to use it as core::arch::asm! is why I don't mind. If it required a separate import line (the way traits do), I'd not be a fan. (That said, this would be terribly inconsistent with how other macros work, so I don't think anybody else would be either)

[joshtriplett]

On Fri, Aug 13, 2021 at 10:46:17AM -0700, Thom Chiovoloni wrote: Ultimately, the fact that you'll be able to use it as `core::arch::asm!` is why I don't mind.

That feels obtrusive in modules that use many, many asm blocks. That contributes to that feeling of "not a native Rust language feature" that I'd like to avoid. You don't have to include a specific header to use `__asm__` in C.

[BurntSushi]

@joshtriplett Could you say more about why you want it to feel like an innate language feature? Is it primarily because it feels that way in C?

[joshtriplett]

@BurntSushi Sure. Off the top of my head, trying to introspect on that feeling: I'm thinking about the mindset associated with one of the types of development that commonly invokes inline assembly: low-level OS/firmware/systems/etc programming. Much like many other compiler attributes that control binary sections, linker attributes, and similar, this feels like something that should have a direct straightforward meaning in code generation, with zero flexibility for the compiler. This is a "drop down to low-level assembly" mechanism, and it fits well into a mindset of thinking of all of your code in terms of the semantics of the underlying assembly.

In addition, assembly is a feature that fundamentally must integrate natively with the compiler's code generation, and can't be done purely using library mechanisms, because it has to handle things like clobbers, and arrange for the right inputs to be in the right registers. So it feels right for it to be built into the language. And something that's available via a specific library path doesn't feel like "part of the language".

(The other common case for inline assembly is optimization, for which I'd expect this to feel like less of an issue.)