Use AnonConst for asm! constants

[Amanieu]

This replaces the old system which used explicit promotion. See #83169 for more background.

The syntax for const operands is still the same as before: const <expr>.

Fixes #83169

Because the implementation is heavily based on inline consts, we suffer from the same issues:

• We lose the ability to use expressions derived from generics. See the deleted tests in src/test/ui/asm/const.rs.
• We are hitting the same ICEs as inline consts, for example ICE: "cannot convert ReErased to a region vid" for let const { "foo" } = "foo" #78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.

[rust-highfive]

r? @petrochenkov

(rust-highfive has picked a reviewer for you, use r? to override)

[RalfJung]

Considering these limitations, is this still something that we want to move forward with?

Well, what are the alternatives? With array repeat expressions not being promotion points any more, and stdarch switching away from rustc_args_required_const, we are close to cutting down promotion to be just about lifetime extension (making &expr have 'static lifetime), as it was originally intended. I still think that is a worthwhile goal, so we should make sure that anything we do here is forward-compatible with such a future.

We lose the ability to use expressions derived from generics.

Note that this affects other situations as well, such as array repeat expressions. We certainly want to fix this in the future. If this is for now "good enough" elsewhere, then why not for asm!?

IMO we should just do the same kind of post-monomorphization evaluation that we do for associated consts and promoteds (AFAIK that would be rather easy to implement, we already have those codepaths for associated consts and promoteds), but @lcnr has plans to ensure that there are no post-monomorphization failures which (to my knowledge) needs a lot of design still.

[petrochenkov]

@bors r+

[bors]

📌 Commit 32be124 has been approved by petrochenkov

[petrochenkov]

This PR is not about syntax, but it seems inconsistent to me that const expressions require braces outside of asm! (at least currently) but not inside of it.

If const loses its braces outside of asm!, then it will work as an unary operator (const a + b => (const a) + b), which will be inconsistent with its meaning in asm!. (See box as an example.)

On the other hand, if asm! gets a "backend" non-macro form (rust-lang/project-inline-asm#8), then it can use const { X } with braces, and surface const X can be desugared into it.
asm! can use such sugar because const ARBITRARY_EXPRESSION in it is well delimited by commas or a closing delimiter, and not by other expressions.

[Amanieu]

The way asm! operands are parsed is actually $operand_type:ident $operand_value:expr where operand_type can be one of in, out, inout, lateout, inlateout, sym, const. The const is not actually parsed as part of an expression, it's just a prefix indicating the type of operand.