Allows early continue/break to error

[LemonInTheDark]

Explanation of control flow parsing because it took me a bit to get

The idea here is to walk the code tree, mark blocks that return/continue/break, and then infect up to parent blocks.

We need to ensure that we only "elevate" a control flow case if it ALWAYS happens when we are executed. We use fuzzy to do this, we're fuzzy if we are unsure, unfuzzy if we aren't.

There's two types of evaluating (and so two patterns)

One type, switches/if blocks, we assume all cases are true, and negate them as we go through all our cases. If all cases have something, we do, if not we don't. If we sometimes don't execute (our case doesn't pass, there's no else), then we're fuzzy and so don't matter to our parent.

The other type is evaluating flat blocks. for these, we just run through them, and if we ever terminate early, mark ourselves dirty.

Fuzzy cases are not allowed to make their parent true, because they do not reflect all possibilities.

What I changed

What I did here was:

• fix fuzzy carrying up into flat blocks, which doesn't make any sense.
• remove fuzzy setting from break/continue, this was needed because return was handled special by flat block merging, but it isn't anymore so...
• guaranteed loops (do whiles, for iterator loops with constant args) will pass returns up to their parent
• added a bunch of tests to try and catch this stuff

Update: More changes

Reworks control flow processing to use bitflags

The idea is, instead of thinking of flags as either fuzzy or not, we think of them as, for our current scope, things that MIGHT happen or things that WILL happen.

So if a return pops up, that WILL happen. But if we return inside an if block, once we're outside that if block returning is something that MIGHT happen.

This allows us to pass stuff up out of guaranteed loops (for/do whiles) better. As an example, if a return will happen inside the loop's block, but a break might happen, then that return should pass outside the for loop as something that might happen, rather then something that will.

It also, I hope, makes the code a little easier to think about. Might just be a me benefit though.

God I hope there's no false positives

I did a survey of some ss13 repos (goon, monkey's eris fork, monkey, tg, bubber, paradise, nebula) and didn't find any false positives.
I did find 2 early continues this catches (an obvious one on monke and the divine light of ifdefs confusing people on goon)

The humble false negative

We don't handle labels correctly, which could lead to continues/breaks being relevant to their parents. I'm going to ignore this because it's stupid and I don't want to have to think about it.

[SpaceManiac]

This is a false positive:

/proc/test()
    for(var/i in 1 to 2)
        if(prob(100))
            continue
        return
    return

Says the second return is unreachable, but it's not.

Goon has a detection like this: https://github.com/goonstation/goonstation/blob/1f7b567faba9790b8b8500575e88d5b9bf2be803/code/modules/sound/managed_positional_sound.dm#L99-L111

[LemonInTheDark]

fuck you're right

[LemonInTheDark]

Rewrote it to use maybe/will flags, used maybe flags to handle that situation correctly. My goon repo was 2 years out of date it looks like.

[LemonInTheDark]

idk why the compiler is panicking, will look further into it at a later time.

[LemonInTheDark]

Update: I have no idea