Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Undectected "undeclared identifier" error #1674

Closed
ducdetronquito opened this issue Oct 21, 2018 · 10 comments
Closed

Undectected "undeclared identifier" error #1674

ducdetronquito opened this issue Oct 21, 2018 · 10 comments
Labels
use case Describes a real use case that is difficult or impossible, but does not propose a solution.
Milestone
0.14.0

Comments

@ducdetronquito
Copy link
Contributor

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
Copy link
Sponsor Contributor

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
Copy link
Contributor

winksaville commented Oct 21, 2018 via email

@thejoshwolfe
Copy link
Sponsor Contributor

thejoshwolfe commented Oct 21, 2018 •
edited
Loading

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
Copy link
Contributor Author

ducdetronquito commented Oct 21, 2018 •
edited
Loading

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
Copy link
Sponsor Contributor

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 :)

@andrewrk andrewrk added this to the 1.0.0 milestone Oct 23, 2018
@marnix
Copy link

marnix commented Oct 3, 2020

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.)

@SpexGuy SpexGuy added the use case Describes a real use case that is difficult or impossible, but does not propose a solution. label Mar 20, 2021
@rohlem rohlem mentioned this issue Aug 13, 2023
Closed
@tau-dev
Copy link
Contributor

tau-dev commented Jul 10, 2024

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

@leecannon
Copy link
Contributor

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

unused globals has not been implemented yet #335

@tau-dev
Copy link
Contributor

tau-dev commented Jul 10, 2024

Right, sorry

@xdBronch
Copy link
Contributor

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

@Vexu Vexu closed this as completed Jul 15, 2024
@Vexu Vexu modified the milestones: 1.0.0, 0.14.0 Jul 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
use case Describes a real use case that is difficult or impossible, but does not propose a solution.
Projects
None yet
Milestone
0.14.0
Development

No branches or pull requests
10 participants
@marnix @thejoshwolfe @andrewrk @winksaville @SpexGuy @leecannon @ducdetronquito @Vexu @tau-dev @xdBronch