-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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.
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
Fmt throws compile-time error on a different call reference #22307
Comments
Update: every fmt in the application now throws a compile error, even the ones that have specifiers: std.log.err("failed creating shader: {s}", .{sdl.SDL_GetError()}); this code now errors, even with the correct specifiers:
this suddenly happened and when I remove a log call, the error just moves to whichever other fmt call is in the compilation order. I am sorry that there I provide no useful ways to reproduce this, I can setup a github repo with the current code. |
Problem solved: std.log.err("failed loading mesh from obj file: {}", .{@errorName(err)}); This code, without a specifier was incorrectly traced and showed up as an error in a different fmt call. |
Given you're using 0.13.0, reference traces pointing to the wrong location sounds like #18900, which has since been fixed. Assuming there aren't too many incompatibilities with your current code due to breaking changes, it might be a good idea to see if Zig master fixes your issue. |
Can't test master due to breaking changes, wanted to migrate on major release. |
@xgallom that last question is probably best suited for e.g the community discord. |
Zig Version
0.13.0
Steps to Reproduce and Observed Behavior
In my source code, in a deinit function, I deinitialize a gpa:
the code produces following compile-time error:
from the stack trace one can find out the line where the bug happens at general_purpose_allocator.zig:391:36:
my thoughts are that from the StackTrace struct, the slice
can be interpreted as a slice of numbers, or a character string. The fmt should contain a specifier.
Did not test if this occurs in a clean project, or if this occurs due to some outside code, but by nature of the bug it seems not.
Expected Behavior
The code compiles without an error. The error was not there before, but none of the changes point to anything having to do with this code being or not being compiled, or being altered in any way.
The text was updated successfully, but these errors were encountered: