Make asm_experimental_arch work in allow_internal_unstable macros

[daxpedda]

This change makes it possible to use unstable asm!, usually requiring feature(asm_experimental_arch), in proc-macros with the allow_internal_unstable attribute.

The test was added on a target where asm! is unstable: Wasm. However, this affects any target with an unstable asm! implementation.

[rustbot]

r? @nnethercote

rustbot has assigned @nnethercote.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[nnethercote]

I have some questions.

• What's the motivation for this? Did it come up in a particular real-world context?
• Presumably targets with stable asm!/global_asm! are unaffected by this?
• The PR description mentions proc macros, but the test uses a declarative macro. Why is this?

I'm also wondering if this will need some kind of libs/lang approval.

View changes since this review

[daxpedda]

• What's the motivation for this? Did it come up in a particular real-world context?

Yes, we are planning to use this in wasm-bindgen.

Currently we encode a bunch of information in really strange ways into the Wasm module and we are planning to make the next version of wasm-bindgen transition to using inline ASM instead. Until it is stabilized, we will basically build a replica of global_asm! ourselves, but we will dynamically detect nightly and switch to use Std's global_asm! instead to future-proof ourselves.

• Presumably targets with stable asm!/global_asm! are unaffected by this?

Yes, this only affects targets requiring asm_experimental_arch: #93335.

• The PR description mentions proc macros, but the test uses a declarative macro. Why is this?

The mechanism is the same, I've double-checked by trying it out locally.
The reason why I didn't add a proc-macro test is because I was just following existing tests for allow_internal_unstable.

Happy to add a dedicated proc-macro test!

[nnethercote]

No need to add a proc macro test. I'll just check on Zulip if we need any kind of libs/lang sign-off, otherwise this looks ok to me.