Add #[loop_match] for improved DFA codegen

[folkertdev]

tracking issue: #132306
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

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

[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

[bors]

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

[folkertdev]

We've done a bunch of work here, and I believe all of the earlier review comments have now been dealt with.

@rustbot ready

[traviscross]

@rustbot author

As a lang matter, this is looking reasonable to me in terms of a lang experiment.

As an impl matter, this is starting to look not unreasonable to me, but I'd like for @Nadrieril to also have a look if he's able.

r? @Nadrieril

@Nadrieril: I still need to raise this in a lang meeting to confirm that everyone is happy to see the experiment here in light of earlier objections, so please don't merge this just yet. You can leave it back in my hands after you're happy with the impl.

Also CC @oli-obk as this work is carrying over some FIXME items you have marked.

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[Nadrieril]

It had skipped my mind that I was the one assigned to this. I have reviewed and approve of the static_pattern_match part as an experiment. I would like someone else to review the rest of this PR.

r? compiler

[BoxyUwU]

Whoops thought I submitted my reviews a couple weeks ago

[BoxyUwU]

Will this not error on:

#[loop_match]
loop {
    struct A;
    struct B;
    state = 'a: match {
       ...
    }
}

Even though attempting to support it down below. I think it'd make sense to just not support defining items here tbh. The full feature will have actual loop match syntax so why go out of our way to support this case.

[folkertdev]

Exactly. We do support it below because it is useful to be able to define macros that capture the label of the labeled block. Here we've not needed it, so we're stricter than necessary but for now that should be OK.

[BoxyUwU]

You're writing const continue as break so that you dont have to go and change all of HIR to have special nodes for const continue and loop match with their own typing rules?

[folkertdev]

Basically, we minimize code duplication in this way, and also const continue as syntax has not yet been agreed on.

[BoxyUwU]

Why do you have const_continue but no const_loop_match? is const loop match unnecessary for getting codegen improvements from the direct jumps with const continues?

[folkertdev]

Only const_continue is needed (really because in rust you can't add more patterns to a match at runtime): the "const" part of the continue just makes sure that we know statically which arm of the match to jump to. Nothing special is needed from the loop.