Step over macro expansions.

[KristofferC]

Sometimes macros expand to a lot of garbage that one is rarely interested in (see the logging macros). If possible, having a mode of the debug commands that steps through macro expanded code could be a good idea.

[davidanthoff]

This would be great, I think ideally something like @info "HELLO" would just behave as if it was a function call: if one sets a breakpoint on such a line, the debugger stops on that line, not the expanded macro code, and if one steps onto such an expression, again the debugger stops on that line, not inside the expanded code. And then one could just step over the whole expression with the normal stepping.

[davidanthoff]

Thinking a bit more about this, maybe we need some kind of "fake" step into a macro step?

So lets say we have some code that looks like this:

foo()
@info "Hello"
bar()

Lets say we had a breakpoint of the call to foo(), and now do a step over. Ideally at that point the debugger would stop on the line @info "Hello". If the user then says next step (i.e. step over), all the code from the macro runs and the next stop occurs on the call for bar().

But if the user selects step into when the debugger is paused on the @info line, then I think the best user experience would be to then stop on the first line of the expanded macro, as if we had just stepped into a function. But of course there is no such thing as a new stack frame, or new function in reality. So maybe the user experience could be something like that, though? I.e. we would have a "fake" step into the expanded macro code?

[timholy]

Stepping to the end of the macro code seems like it might be implementable by looking at the line table?

[aminya]

Is there a way to debug the code that macro generates? I think this issue limits debugging macros instead of helping it.

macro itself(expr)
	return expr
end

We should be able to step through these sentences:

@itself begin
   a = 2;
   b = a;
end

[KristofferC]

You can just hoist the part computing the output expression into a function and debug that one.

[aminya]

You can just hoist the part computing the output expression into a function and debug that one. Yes, it is possible to use @macroexpand, then define a function, then copy-paste the @macroexpand output, and then debug the function call.

• The procedure is very inconvenient and it should be automated instead of the error-prone manual copy-paste, definition, etc.
• This is very hard or impossible if the macro is inside a big program.

[KristofferC]

I don't get what you mean.

macro foo(expr)
    _foo(expr)
end

function _foo(expr) 
  ... 
end

and debug _foo

[aminya]

So what if the macro call is part of a bigger program?

[KristofferC]

It doesn't really make sense to me to debug the macro expansion during runtime because that is not when it is executed.

[aminya]

It doesn't really make sense to me to debug the macro expansion during runtime because that is not when it is executed.

Here I didn't mean the macro expansion, but the code it generates. Imagine a user calls a macro in their program and wants to debug the code. See here as an example: https://github.com/JuliaMusic/MusicXML.jl/blob/1fb530f6fa9527d7b686007437a40041f6f44216/examples/creating.jl#L3

The actual macro debugging is possible using a function.

[KristofferC]

Here I didn't mean the macro expansion, but the code it generates.

Oh, I got confused because that already works.

[davidanthoff]

@aminya the issue here is meant to make stepping through the generated code more like stepping through a function, with an option to just step over it in one go.

[aminya]

@aminya the issue here is meant to make stepping through the generated code more like stepping through a function, with an option to just step over it in one go.

I see. if you give us the option to switch it off or on based on our needs that would be awesome!