Document asm_cfg inline assembly attributes

[PLeVasseur]

Summary

• document asm_cfg attribute support on inline assembly templates/operands and update the inline-assembly grammar
• add attribute legality rules and an example under the asm macros section
• record syntax/paragraph updates in the Rust 1.93.0 changelog entry
• Closes [Change]: [1.93] Stabilize asm_cfg #647

Reference alignment

• Reference PR: document cfg conditions on inline assembly templates and operands reference#2063
• Reference sections: https://doc.rust-lang.org/reference/inline-assembly.html#syntax, https://doc.rust-lang.org/reference/inline-assembly.html#attributes
• Grammar: Reference introduces AsmAttrFormatString/AsmAttrOperand; FLS introduces AssemblyTemplate/AssemblyAttribute* wrappers to match, splitting operands into RegisterArgument, AbiClobber, and AssemblyOption
• Legality: cfg/cfg_attr support and the template-first rule match the Reference; FLS makes cfg-false argument behavior explicit to align with conditional compilation semantics
• Reference note about rustc attribute handling is omitted because it is implementation detail without semantic effect

Testing

• ./make.py

[PLeVasseur]

Hey @tshepang, @kirtchev-adacore -- could this be reviewed?

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[kirtchev-adacore]

Pete,

How about adding a paragraph before this one which defines "inline assembly argument"? Something along the lines of

An :t:`inline assembly argument` is either an :t:`assembly instruction`, a :t:`register argument`, an :t:`ABI clobber`, or an :t:`assembly option`.

(with a :dt:inline assembly argument in the Glossary)

[PLeVasseur]

Added a local definition before the legality rule and a matching glossary entry for :t:inline assembly argument``.

The new definition is:
An :t:inline assembly argument is either an :t:assembly instruction, a :t:register argument, an :t:ABI clobber, or an :t:assembly option.

This is now present in src/inline-assembly.rst and src/glossary.rst, and the changelog records the new glossary term.

[kirtchev-adacore]

Suggested change

	Only :t:`attribute` :c:`cfg` and :t:`attribute` :c:`cfg_attr` shall decorate :t:`[assembly instruction]s`, :t:`[register argument]s`, :t:`[ABI clobber]s`, and :t:`[assembly option]s` in :s:`AsmArguments` and :s:`GlobalAsmArguments`; all other :t:`[attribute]s` shall be rejected.
	Only :t:`attribute` :c:`cfg` and :t:`attribute` :c:`cfg_attr` shall decorate :t:`[inline assembly arguments]s in :s:`AsmArguments` and :s:`GlobalAsmArguments`.

Note that "all other attributes shall be rejected" does not make sense as a rule because it implies that the programmer shall be rejecting the attributes, not the confirming tool. Normative "shall" and "must" are for the programmer to obey, facts are what a conforming tool guarantees.

[PLeVasseur]

Reworked this into a pure legality rule using the newly defined inline assembly argument term:
Only :t:attribute :c:cfg and :t:attribute :c:cfg_attr shall decorate :t:[inline assembly arguments]sin:s:AsmArguments`` and :s:GlobalAsmArguments``.

I also removed the all other attributes shall be rejected clause so the paragraph no longer mixes a programmer-facing rule with tool behavior.

[kirtchev-adacore]

Suggested change

If a :t:`assembly instruction`, :t:`register argument`, :t:`ABI clobber`, or :t:`assembly option` in :s:`AsmArguments` or :s:`GlobalAsmArguments` is subject to :t:`attribute` :c:`cfg` or :t:`attribute` :c:`cfg_attr` where the related :t:`configuration predicate` evaluates to ``false``, then that construct is not considered part of the related :s:`AsmArguments` or :s:`GlobalAsmArguments`, consistent with :t:`conditional compilation`.

If an :t:`inline assembly argument` in :s:`AsmArguments` or :s:`GlobalAsmArguments` is subject to :t:`attribute` :c:`cfg` or :t:`attribute` :c:`cfg_attr` where the related :t:`configuration predicate` evaluates to ``false``, then the :t:`inline assembly argument` is not considered part of the related :s:`AsmArguments` or :s:`GlobalAsmArguments`, consistent with :t:`conditional compilation`.

I wonder whether this paragraph is even needed because it is subsumed by

18.6:3 A construct subject to attribute cfg where the related configuration predicate evaluates to false is not considered part of a Rust program.

[PLeVasseur]

I ended up removing the standalone paragraph.

The generic conditional-compilation rule in 18.6 already covers the cfg-false case, so keeping a separate paragraph here seemed redundant. I kept the asm-specific template-first rule and tightened it so the cfg-disabled operand case is still covered locally where that unique behavior matters.