compiler: implement labeled switch/continue

[mlugg]

Implements #8220.

This is a revival of #19812.

@Luukdegram, you might want to check the Wasm changes -- I rebased your work, but haven't tested it, so the rebase could have gone wrong somewhere, not sure. It's probably fine? (oops, the commit authorship info got lost, sorry!)

@jacobly0, I haven't implemented the new syntax in the x86_64 backend. If you'd like to do this imminently on this PR, feel free; otherwise I'll let you do it on master in your own time.

@Rexicon226, I've regressed some bits of the RISC-V backend, specifically loops and switches containing ranges. I can probably fix them up (loops certainly should be easy), but it might be easier if you can take a look?

[Rexicon226]

@Rexicon226, I've regressed some bits of the RISC-V backend, specifically loops and switches containing ranges. I can probably fix them up (loops certainly should be easy), but it might be easier if you can take a look?

You got it!

[Luukdegram]

This is a revival of #19812.

@Luukdegram, you might want to check the Wasm changes -- I rebased your work, but haven't tested it, so the rebase could have gone wrong somewhere, not sure. It's probably fine? (oops, the commit authorship info got lost, sorry!)

Looks good! Thanks for doing the work.

[andrewrk]

Brilliant work as usual, @mlugg

Don't forget the release notes writeup while it's fresh in your mind :)

[mlugg]

Release notes are below.

---

Labeled switch

Zig 0.14.0 implements an accepted proposal which allows switch statements to be labeled, and to be targeted by continue statements. Such a continue statement takes a single operand (like break can to return a value from a block or loop); this value is treated as a replacement operand to the original switch expression. This construct is semantically equivalent to a switch statement inside of a loop, with a variable tracking the switch operand; for instance, the following tests are equivalent:

test "labeled switch" {
    foo: switch (@as(u8, 1)) {
        1 => continue :foo 2,
        2 => continue :foo 3,
        3 => return,
        4 => {},
    }
    return error.Unexpected;
}

test "emulate labeled switch" {
    var op: u8 = 1;
    while (true) {
        switch (op) {
            1 => { op = 2; continue; },
            2 => { op = 3; continue; },
            3 => return,
            4 => {},
        }
        break;
    }
    return error.Unexpected;
}

These constructs differ in two ways. The most obvious difference is in clarity: the new syntax form is clearer at times, for instance when implementing Finite State Automata where one can write continue :fsa new_state to represent a state transition. However, a key motivation for this language feature lies in its code generation. This is expanded on below.

It is also possible to break from a labeled switch. This simply terminates evaluation of the switch expression, causing it to result in the given value, as though the case body were a labeled block. As with blocks, an unlabeled break will never target a switch statement; only a while or for loop.

Unlike a typical switch statement, a labeled switch with one or more continues targeting it is not implicitly evaluated at compile-time (this is similar to how loops behave). However, as with loops, compile-time evaluation can be forced by evaluating such an expression in a comptime context.

Code Generation Properties

This language construct is designed to generate code which aids the CPU in predicting branches between cases of the switch, allowing for increased performance in incredibly hot loops, particularly those dispatching instructions, evaluating FSAs, or performing similar case-based evaluations. To achieve this, the generated code may be different to what one would intuitively expect.

If the operand to continue is comptime-known, then it can be translated to an unconditional branch to the relevant case. Such a branch is perfectly predicted, and hence typically very fast to execute.

If the operand is runtime-known, then each continue can become a separate conditional branch (ideally via a shared jump table) back to the same set of potential branch targets. The advantage of this pattern is that it aids the CPU's branch predictor by providing different branch instructions which can be associated with distinct prediction data. For instance, when evaluating an FSA, if case a is very likely to be followed by case b, while case c is very likely to be followed by case d, then the branch predictor can use the direct jumps between switch cases to predict the control flow more accurately, whereas a loop-based lowering causes the state dispatches to be "collapsed" into a single indirect branch or similar, hindering branch prediction.

This lowering can inflate code size compared to a simple "switch in a loop" lowering, and any Zig implementation is, of course, free to lower this syntax however it wishes provided the language semantics are obeyed. However, the official ZSF compiler implementation will attempt to match the lowering described above, particularly in the ReleaseFast build mode.

[andrewrk]

Follow-up issue for docs:

• langref docs for labeled switch/continue #21375

Nice demo of this in action:

• Faster tokenizer #21367

[nm-remarkable]

The ziglings project now supports this feature https://codeberg.org/ziglings/exercises/pulls/161