ETA: Oh this is even better: `if (false)` code can (as of 0.10) run even outside field assignment: https://github.com/ziglang/zig/issues/12040
Like I said, joke language. I define that as a toy language which is badly broken by design. Kind of like LOLCODE except I doubt LOLCODE runs `if (false)` code.
More issues with `if`: https://github.com/ziglang/zig/issues/10349 https://github.com/ziglang/zig/issues/8952 https://github.com/ziglang/zig/issues/4491 https://github.com/ziglang/zig/issues/5230 https://github.com/ziglang/zig/issues/6444 https://github.com/ziglang/zig/issues/7097
This one is quite funny. Normally you'd use `if (a) ... else |b| ...` if the type of `a` was an error union, and you'd get the `if` branch if it was not an error and the `else` branch if it was an error. So I suspect that there's a coercion from bool to some error union here. Error unions with lazily computed error sets are allowed, and (as a result of this or of other choices about the ergonomics of conditionally-compiled code that would be made of #typedefs in C) error unions with empty error sets are allowed. Wow.
The stage1 compiler is currently being phased out for the stage2 compiler (Zig implementation). As of current master branch, stage1 is disabled by default (can be re-enabled with `-fstage1`) in favor of stage2.
2) The miscompilation in question is `if (false) else |capture| {}` not just `if (false)`. The latter is misinformation.
3) Miscompilations are conditional. Saying that the entire compiler is invalid given they exist is like saying rustc is invalid / can't uphold safety invariants given long standing compiler bugs allowing safe code to trigger UB / segfault [0] [1]. Both of such conclusions aren't true in practice.
[0]: https://crates.io/crates/fake-static [1]: https://github.com/rust-lang/rust/issues/25860
I cannot provide the full program in which it failed, and the small programs I tried did not cause it to fail at the time.
I sort of expect these things to be fixed though. Like, eventually both Zig and unsafe Rust will actually have defined semantics, and eventually expressions containing `if (false) { X(); }` will not call X, and so on.
Edit: after seeing the linked issue in a sibling comment, this is even less surprising. stage1's handling of basically any complex expression in struct/tuple literals is quite bad. I've mostly had it crash the compiler, but it's not surprising that it can also just evaluate incorrectly. It seems plausible that the actual solution to all this is to use stage2 instead, but we cannot move all of our programs to stage2 today because we use async.