Undectected "undeclared identifier" error

[ducdetronquito]

Hi !

When playing with the JSON parser of the standard library, I came across an undected "undeclared identifier" error with the following snippet:

const warn = @import("std").debug.warn;
const json = std.json;

pub fn main() void {
   warn("Hello World!\n"); 
}

At line 2 const json = std.json; the std is not declared but the program compile and run fine.

It is only when I try to call something from the json variable that the error is detected:

const warn = @import("std").debug.warn;
const json = std.json;

pub fn main() void {
   warn("Hello World!\n"); 
   var p = json.TokenStream.init(json_source);
}

The previous snippets produce the expected error:

➜ zig build-exe hello.zig
path/to/hello.zig:6:34: error: use of undeclared identifier 'json_source'
   var p = json.TokenStream.init(json_source);
                                                   ^

[thejoshwolfe]

the behavior you're describing is intentional. zig lazily analyzes top level declarations (like json in your example), so any semantic errors in the initializer expression are not reported unless the value is potentially usable from an entry point (the main function in your example).

This is how zig deals with situations where C programmers would typically use #ifdef. When you're writing target-specific code, functions may not exist in some build configurations or may be defined with different signatures. In C you would use the preprocessor to omit the inactive code from compilation, but in zig, you just don't call the code according to conditions that can be evaluated at compile time.

So if your example had referenced json but only behind an if (false), you'd still not get any error.

[winksaville]

On one hand I see the value of this, but on the other hand it's disconcerting that obvious errors are not caught.

…

On Sun, Oct 21, 2018, 8:20 AM Josh Wolfe ***@***.***> wrote: the behavior you're describing is intentional. zig lazily analyzes top level declarations (like json in your example), so any semantic errors in the initializer expression are not reported unless the value is potentially usable from an entry point (the main function in your example). This is how zig deals with situations where C programmers would typically use #ifdef. When you're writing target-specific code, functions may not exist in some build configurations or may be defined with different signatures. In C you would use the preprocessor to omit the inactive code from compilation, but in zig, you just don't call the code according to conditions that can be evaluated at compile time. So if your example had referenced json but only behind an if (false), you'd still not get any error. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1674 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-hHD0939V1otoL-dAFw93ck5l6mniPks5unJCfgaJpZM4XygLx> .

[thejoshwolfe]

There is a vague plan to someday be able to do a multistate "non-deterministic" evaluation of all possible compile-time branches depending on any build configuration. The result is that all your code would be classified as either active, inactive because of build variables (like target os), or completely dead and unreachable regardless of build variables. The json example above is the third category: completely unreachable.

We could consider making it an error to have dead code like that, but i'm not sure that's the right thing to do. At the very least, it would be great to see some kind of indication in an IDE, like the background turning gray, to indicate that the code is dead. That would help communicate what's going on and eliminate confusion.

[ducdetronquito]

Ok I got the intent !
But as @winksaville said, it also feels weird to let this potential error being unnoticed.

We could consider making it an error to have dead code like that [...]

Would it be possible to have warnings when compiled in non-release mode ? Maybe with some optional arguments like zig build-exec --warns-for-unreachable-code hello.zig.

Like you said, it could be tackled by a proper IDE plugin, but not everyone uses an IDE :)

[thejoshwolfe]

We don't have any plans to add warnings to Zig. If Zig was going to report the problem, it would be an error. In that case, the compiler needs to be certain that reporting an error is the right thing to do, which is currently too difficult to determine, hence silence on the matter.

Any IDE features Zig provides in the future would also be accessible somehow without an IDE, such as through an ssh terminal. Those plans are vague and distant however.

In the mean time, we have no solution to reporting unused code or semantic errors in unused code. The solution is to use the code so that the compiler analyzes it. At least this encourages writing tests :)

[marnix]

Is there any specific action that anyone can take on this issue, within the planned 1.0.0 scope?

Except for documenting the

test "" {
    std.meta.refAllDecls(@This());
}

trick somewhere?

(Note: That doc would need to change when #6436 is done.)

[tau-dev]

Sounds like this issue has been resolved by https://ziglang.org/download/0.9.0/release-notes.html#Compile-Errors-for-Unused-Locals.

[leecannon]

@tau-dev this is regarding a global not a local

unused globals has not been implemented yet #335

[tau-dev]

Right, sorry

[xdBronch]

this has been fixed but for a different reason. in 0.9 usingnamespace was changed to no longer bring identifiers into scope meaning the error for this was moved from sema into astgen so its caught unconditionally. this isnt really related to unused variables