How do I view the results of comptime expansion?

Help
1

This is my mental model of how comptime works → 

fn add(a: anytype, b:@TypeOf(a)) @TypeOf(a) {
  return a+b;
}

const float1 : f32 = 1;
const float2 : f32 = 2;
const int1: usize = 1;
const int2: usize = 2;

const float3 = add(float1, float2);
const int3 = add(int1, int2);

// on compilation add will expand to the following functions
fn add_anon123(a: f32,b:f32) f32 {}
fn add_anon234(a:usize, b:usize) usize {}

I have seen these anon_### functions in crash logs and debug things.
I assume they are somewhere in .zig_cache, or maybe not.

What is the simplest way for me to find these generated functions?

2

objdump :wink:

Kidding aside, there is no such thing as comptime expansion; there is only comptime evaluation. Generic instantiation is done at the same time as semantic analysis. No Zig code is generated. ZIR in, AIR out.

5 Likes
3

image
image1069×258 15.2 KB

So does that the “code” for functions like deserialize__anon_115844() here is never generated, but just the AST (and lower levels)?
So the function names are just for debugging?

4

andrew explained why no such thing exists.

comptime is imo straight forward enough that such a thing isnt particularly needed, you have already figured out your own example.

That being said, @compileLog is good for comptime print debugging.

I have also heard whispers of a comptime debugger…
I cannot confirm that, perhaps someone else could…

1 Like
5

no ast is generated, that would be generating zig.

the anon function names are needed because of how linking works, at that point they are names for chunks of AIR/assembly/machine code

2 Likes
6

comptime is imo straight forward enough that such a thing isnt particularly needed, you have already figured out your own example.

while comptime is far more straightforward than something like Rust macros, there have been times I’ve yearned for a debugger to step through the evaluation of the comp time code.

4 Likes
7

Me too
however, the whispers continue to not be confirmed

1 Like
8

I don’t know how far along jacobly got with it, but he was talking about making it so that when you use his LLDB fork and the x86 backend, you can step through comptime logic.

7 Likes
9

You’re looking at mangling. Any language which has overloading will have mangling, because of how object formats work.

Zig has overloading because of type creation at comptime and the use of anytype. So each specialization of a function on that basis needs a mangled name.

3 Likes