4 ms·

As someone considering whether to learn rust or zig next for hobby projects, this does seem a pretty big deal breaker for zig, at least in its current state. Bu

by runald 4y ago

As someone considering whether to learn rust or zig next for hobby projects, this does seem a pretty big deal breaker for zig, at least in its current state. But since zig still hasn't really even reached the 1.0.0, it is expected to have compiler bugs like this? Or do you believe this is something that can't be fixed due to fundamental language design?

kprotty 4y ago
It's not expected to have miscompilation bugs like this by 1.0. These are bugs in the stage1 (original C++) compiler implementation, not language design issues as the poster claims. The language still has design issues that are being addressed (result location, async, etc.) but they're unrelated to `if` bugging out in this case. 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.
- puffoflogic 4y ago
  Stage2 is like a Band-Aid on an amputee. It is built with stage1. Any compiler built such that `if (false)` branches can run will also miscompile code, even if its source is 100% correct. (Spoiler alert: its source will not be 100% correct.)
  - kprotty 4y ago
    1) Stage2 is intended as more than just fixes for stage1; It includes performance improvements, more codegen backends (direct x86/arm/wasm to avoid LLVM, C, etc.), will allow for incremental linking, hot reloading, and more. 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 https://crates.io/crates/fake-static [1]: https://github.com/rust-lang/rust/issues/25860 https://github.com/rust-lang/rust/issues/25860
  - kristoff_it 4y ago
    It's not uncommon for LLVM releases to come with regressions that cause miscompilations. The compiler toolchain industry is very different from what you seem to think it is.

by runald 4y ago

kprotty 4y ago

It's not expected to have miscompilation bugs like this by 1.0. These are bugs in the stage1 (original C++) compiler implementation, not language design issues as the poster claims. The language still has design issues that are being addressed (result location, async, etc.) but they're unrelated to `if` bugging out in this case. 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.

puffoflogic 4y ago
Stage2 is like a Band-Aid on an amputee. It is built with stage1. Any compiler built such that `if (false)` branches can run will also miscompile code, even if its source is 100% correct. (Spoiler alert: its source will not be 100% correct.)
- kprotty 4y ago
  1) Stage2 is intended as more than just fixes for stage1; It includes performance improvements, more codegen backends (direct x86/arm/wasm to avoid LLVM, C, etc.), will allow for incremental linking, hot reloading, and more. 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 https://crates.io/crates/fake-static [1]: https://github.com/rust-lang/rust/issues/25860 https://github.com/rust-lang/rust/issues/25860
- kristoff_it 4y ago
  It's not uncommon for LLVM releases to come with regressions that cause miscompilations. The compiler toolchain industry is very different from what you seem to think it is.