Add #[loop_match] for improved DFA codegen

[folkertdev]

tracking issue: #138777
project goal: rust-lang/rust-project-goals#258

This PR adds the #[loop_match] attribute, which aims to improve code generation for state machines. For some (very exciting) benchmarks, see rust-lang/rust-project-goals#258 (comment)

Currently, a very restricted syntax pattern is accepted. We'd like to get feedback and merge this now before we go too far in a direction that others have concerns with.

current state

We accept code that looks like this

#[loop_match]
loop {
    state = 'blk: {
        match state {
            State::A => {
                #[const_continue]
                break 'blk State::B
            }
            State::B => { /* ... */ }
            /* ... */
        }
    }
}

• a loop should have the same semantics with and without #[loop_match]: normal continue and break continue to work
• #[const_continue] is only allowed in loops annotated with #[loop_match]`
• the loop body needs to have this particular shape (a single assignment to the match scrutinee, with the body a labelled block containing just a match)

future work

• perform const evaluation on the break value
• support more state/scrutinee types
• report proper errors when the jump target could not be determined statically
• rework the pattern matching logic so hopefully it can use more existing code

maybe future work

• allow continue 'label value syntax, which #[const_continue] could then use.
• allow the match to be on an arbitrary expression (e.g. State::Initial)
• attempt to also optimize break/continue expressions that are not marked with #[const_continue]

r? @traviscross

[rustbot]

Some changes occurred in match checking

cc @Nadrieril

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

Some changes occurred in rustc_ty_utils::consts.rs

cc @BoxyUwU

[traviscross]

Thanks @folkertdev for putting up this PR. The big picture looks right, in terms of the behavior of the tests and how to approach the experiment in terms of starting with the attributes for thiis.

This is a first partial pass on the details.

@rustbot author

[traviscross]

Probably the body of this match arm should be broken out and located elsewhere, in the same way that match_expr is, and should have a substantial doc comment above it, like match_expr does.

[traviscross]

If this is unreachable, it's worth marking it that way. Either way, it's worth a comment about this.

[traviscross]

What's the story here?

[bjorn3]

Dropping the rest of the local variables when unwinding out of drops on #[const_continue] isn't implemented yet.

[folkertdev]

Thanks for the detailed review!

I've fixed a bunch of the low-hanging fruit (e.g. in the tests). For the actual pattern matching logic, I have a branch with what I believe is a better solution that re-uses more existing pattern matching infra. We'll come back to that here once björn has had a chance to look at it.

[rustbot]

Some changes occurred in exhaustiveness checking

cc @Nadrieril

Some changes occurred in match lowering

cc @Nadrieril

[folkertdev]

@bjorn3 just noticing, this should probably get its own function. it does not really share any logic with the others in break_scope at all (currently anyway)

[bors]

☔ The latest upstream changes (presumably #138974) made this pull request unmergeable. Please resolve the merge conflicts.