ziglang
translate-c: support goto statements
Goto support works by creating a boolean variable per label, which is false by default. A goto changes this variable to true and breaks to the highest common scope of the goto and the label. Now, if and while statements, which are controlled by the boolean variable, jump over the execution part of the code to get to the label.
closes #11992
I think I completed this PR now. It lacks the ability to use goto to jump out of or within a statement expression, but I don't think there is much need for this.
As I stated in a87c4700247c7e1f15b40e777bc16fdf66bdf275 this PR also fixes #14809.
This PR inserts while loops which exist not as while loops in the c code. These loops have the same issues as descripted in #15155/#16790.
Shouldn't a feature like this wait on #19812? That will be a more performant and general way to translate gotos into Zig, without adding extra conditionals to the code.
Shouldn't a feature like this wait on #19812? That will be a more performant and general way to translate gotos into Zig, without adding extra conditionals to the code.
@mnemnion I don't see how #19812 will make this more performant or general. I have not seen any c code snippet, where llvm does not optimize away the goto-variable generated by this PR.
For the translation of c-switch statements, I argree. Translate-c outputs zig code multiple times, if the code is accessible by multiple cases. This PR makes translate-c also output case code once more, if the case is accessed by a goto. But this rewrite would be translate-c-switch specific and not translate-c-goto specific.
This PR makes translate-c also output case code once more, if the case is accessed by a goto. But this rewrite would be translate-c-switch specific and not translate-c-goto specific.
Thanks for the reply. My main intention was to bring that branch to your attention, if you weren't aware of it, I apologize if it came across as second-guessing.
Many non-trivial uses of goto are in complex case statements, particularly those implementing a VM dispatch loop, a case (heh) that the labeled continue branch is specifically designed to handle. You say that would constitute a distinct branch? I believe you. Cheers.