Undetected Errors in Unused Code: A Feature or Oversight?

[joelonsql]

Zig Version

0.11.0

Steps to Reproduce and Observed Behavior

Errors in Uncalled Functions: Balancing Efficiency and Precision

Overview:

Greetings Zig team,

Having delved into the Zig ecosystem and being guided by its "Zen", I've come to appreciate the ethos that drives Zig's development. Specifically, points such as "Communicate intent precisely" and "Compile errors are better than runtime crashes" resonate deeply. However, during my journey, I've encountered an aspect of the compiler's behavior that has spurred some reflection.

Reproduction Steps:

1. Let's consider a minimal example:

dead_code_issue.zig:

const std = @import("std");

pub fn activeFunction() void {
    std.debug.print("This function is regularly called.\n", .{});
}

pub fn dormantFunctionWithError() void {
    // A misalignment: Initializing a 3-element array with 2 values.
    var arr: [3]u8 = [1]u8{0} ** 2;
    _ = arr; 
}

main.zig:

const dead_code = @import("dead_code_issue.zig");

pub fn main() void {
    dead_code.activeFunction();
}

2. Upon compiling main.zig, the compiler overlooks the error in dormantFunctionWithError, given its dormant status.

Reflecting on the Zen:

Now, in the spirit of "Reduce the amount one must remember", it's understandable that the compiler might not want to rummage through uncalled code. The rationale might be rooted in efficiency, minimizing compile time, and focusing on the actively utilized parts.

Yet, in line with the principle that "Edge cases matter", it feels that these overlooked sections could become potential pitfalls. As developers, our intent, as Zig rightly prompts us to, is to "Communicate intent precisely". Thus, even if a function isn't active now, it's a reflection of some future intent.

Proposal:

Given the philosophy that "Compile errors are better than runtime crashes", it could be beneficial to have a compiler flag that enforces a thorough examination of all code, irrespective of its immediate usage. This ensures that when the dormant code is activated, we're not blindsided by latent issues.

In the continuum of "Incremental improvements", I believe this could be a valuable step towards aligning with Zig's vision even more closely.

Thank you for your dedication and for fostering a community where "Together we serve the users".

Expected Behavior

error: expected 0 array elements; found 1
var arr: [2]u8 = [0]u8{0} ** 2;
~~~~~^~~

[rohlem]

Just wanted to note that this concern has been brought up several times before: #1674 , #2529 , #3028 , and I'm sure several others. Maybe also of interest: std.testing.refAllDecls and the trick of comptime {_ = decl; _ = &function;} to force analysis of a decl and a function.

( FWIW, I think there's valuable discussion to be had about this, however it doesn't currently seem like a pressing concern in active development. Totally random personal guess - it might be relevant again in 1-2 years from now, when the package manager, language, and compiler (esp. custom backends) have had time to settle in and adapt to each other. )

[ifreund]

I don't think there's anything new to talk about here that isn't covered by the existing issues.