Std.debug.assert() -- only reporting the caller's caller

Help
1

foo() calls bar(), which in turn calls std.debug.assert() with a false condition… is there way to just report the call-site inside foo()???

standing backing, i’m doing a lot of “semantic validation” inside functions i provide… ideally, i would be able simply report the @src() infomation about my caller…

some of this validation can actually be done at comptime; but in some cases function parameter values aren’t known until runtime… either way, i’d like these to “look-and-feel” as much as possible like standard compiler errors…

2

So you’re asking for something like…

foo(); // calls bar with assert false

Which then reports something like:

line xyz (inside foo): bar asserted false

I wonder if you could do something by forcing an inline to achieve this (of course there’s other concerns about whether you would want to inline… just throwing out ideas here).

3

exactly… just like the sort of message i receive from the compiler were i to call foo() with the wrong number and types of arguments…

even @comptimeError would benefit from this feature…

indeed, we’ve seen plenty of examples in which an anytype parameter undergoes further semantic analysis… likewise when we want to verify that a particular pattern is being followed, etc.

in general, imposing a “design-by-contract” veneer onto one’s code often finds it implementation via assert statements (for function pre- and post-conditions)…

4

@biosbob, have you checked out this thread: Implementing Generic Concepts on Function Declarations

I don’t ascribe to the techniques there in my own code for Zig anymore, but there was a lot of great thinking and you might have some more insight into building a better mousetrap.

2 Likes
5

a little late to the party, but i have started implementing comptime checks in a similar manner… here’s a snip to give you an idea:

pub fn asI(I: type, U: type) I.em__I {
    comptime {
        if (!U.em__U.hasInterface(I.em__U)) {
            @compileError(std.fmt.comptimePrint("{s} does not inherit {s}", .{ U.em__U.upath, I.em__U.upath }));
        }
    }
    return mkIobj(I.em__I, U);
}

this “works”, in that i get a nice compiler error stating that {s} does not inherit {s}… very descriptive, except that the file and line number are referencing the location of my @compileError and NOT the location in my user’s code when they actually called asI(...)

i’ve seen techniques using @returnAddress at runtime to identify the call site… i just don’t know if there is a moral equivalent for comptime…

6

Could this be due to inlining, since Zig’s stack trace dumping machinery has to walk the stack, and I’m not sure if it grabs inline functions from the DWARF info?

7

somebody correct me if i’m wrong, but i don’t think @returnAddress makes any sense within a comptime block… the compiler presumably “interpreted” a call to my asI function found somewhere in my sources; i just want to know where that comptime call site is…

8

Oh, sorry, I didn’t notice this was in comptime land :sweat_smile: I don’t know what the behavior of @returnAddress in comptime is.