Weird error with std.debug.print + "-freference" not working

Help
1

Hi, I’m not really sure where to talk about this.

I figured it out but while doing ziglings I had this error:

Compiling: 058_quiz7.zig
error: the following command failed with 1 compilation errors:
zig-x86_64-linux-0.15.1/zig build-exe /ziglings/exercises/058_quiz7.zig --cache-dir ziglings/.zig-cache --listen=-
zig-x86_64-linux-0.15.1/lib/std/Io/Writer.zig:1120:51: error: expected type '[]const u8', found '*const 058_quiz7.Place'
                        const slice: []const u8 = value;
                                                  ^~~~~
referenced by:
    print__anon_22980: zig-x86_64-linux-0.15.1/lib/std/Io/Writer.zig:700:25
    print__anon_22916: zig-x86_64-linux-0.15.1/lib/std/debug.zig:231:23
    8 reference(s) hidden; use '-freference-trace=10' to see all references

I couldn’t use the -freference-trace=10 flag, it wouldn’t change the output, so I was a little lost.

Turned out I was just using the structs directly instead of using a value.

.place => |place| print("{s}",    .{place}),
.path  => |path|  print("--{}->", .{path}),

instead of

.place => |place| print("{s}",    .{place.name}),
.path  => |path|  print("--{}->", .{path.dist}),

This error didn’t appear until I fixed the other errors so I didn’t think immediately about the prints at the very beginning.

Are these bugs?
Is the flag not working because of how ziglings is built? if so how can I dig deeper in the trace?

2

Not a bug.

It’s just that in case of errors in formatting (typically in calls to std.debug.print and the like), the error messages of the compiler are absolutely not helpful, in particular because they point into the std lib and not to the corresponding line of your own program.

Personally, I consider this the biggest downside of Zig.

Practically all other error messages of the compiler are useful.

I hope that one day the error message will be improved.

Zig has enough upsides which outweigh this confusing messages, so I learned to just accept it and be very careful with formatting.

3

This isn’t true at all, in normal cases passing -freference-trace will give you either very many or unlimited number of reference traces (not sure which) and then you just need to look at the files to spot the first one that is actually within your code.

4

I think it is likely that @bunxen is using the default way to run ziglings and it seems that that doesn’t pass the reference-trace argument for some reason, I think it is likely that there would be some way to improve the ziglings build.zig so that it works. Would need to look into it a bit more.

For now it should be possible to instead run it directly, based on:

Try this:

zig run /ziglings/exercises/058_quiz7.zig -freference-trace
5

Hmm I think ziglings still runs on an older dev version of Zig?

6

I see, thank you I tried with run and it did allow for showing more of the trace

also I read a little that this is because it’s a type error, I’m not sure I grasp the nuance but yeah I’ll just be careful of format stuff

7

The {s} expects a slice of bytes, or something that can coerce to that, that’s what the assignment the error is coming from is for. But your type can’t coerce to that so you get a type error.

8

So within build.zig there is this within the compile function:

        const cmd = switch (self.exercise.kind) {
            .exe => "build-exe",
            .@"test" => "test",
        };
        zig_args.append(cmd) catch @panic("OOM");

        // Enable C support for exercises that use C functions.
        if (self.exercise.link_libc) {
            zig_args.append("-lc") catch @panic("OOM");
        }

        // NOTE I added this if below to forward the -freference-trace
        // NOTE passed to: zig build -freference-trace
        // NOTE to the command that compiles the exercise
        if (b.reference_trace) |rt| {
            zig_args.append(b.fmt("-freference-trace={}", .{rt})) catch @panic("OOM");
        }

I created a pull request here: #294 - pass -freference-trace to executed compile command - ziglings/exercises - Codeberg.org

9

Thanks for this info.

Actually -freference-trace never caught my eye.
And (not tried yet myself) from some output examples, it seems that it would help, but at the price of adding a lot of verbosity to the output, which probably is the reason why this option is not enabled by default.

+1 for @Vexu’s proposal in

Given how much time already was spent on helping users individually over the years, explaining what they did wrong in these cases of unhelpful error messages and how to find out where, I think actually solving this once and for all would be a good idea.