Feature Request: Breakpoints 'after' statements

[smarr]

For stepping operations on asynchronous message sends, as well as for an expressive breakpoint language, it is useful to have breakpoints after a statement.

Specifically, we use it to implement breakpoints that activate before the completion of an asynchronous message send. This is to know which result a promise is going to be resolved to.
In a sequential language, that would be before returning from a method. I haven't really seen it in a debugger, but often missed the ability to inspect and change return values before returning.

A sketch is implemented here: smarr@a4b4d2b

[entlicher]

Breakpoints are submitted on statements. Don't you need this rather for call nodes?
This reminds me method breakpoints in Java where you can have method enter / method exit events. And the method exit event gives you the return value. I can imagine to add a possibility to modify the return value as well.

[smarr]

It is to break after the last statement is executed in a method, and before we return from that statement. So, call node would be in the caller, which would probably also be interesting, but for my use case I wanted to see the callee.

My 'callee' resolves as last implicit action a promise, enabling the scheduling of another activity. So, before that happens, I want to be able to break, and then step through the consequences one by one.

[smarr]

Btw, @eregon pointed out, that I am not handling the exception case yet.

[mlvdv]

I agree that this would be very useful; thanks.

[smarr]

And, just because there was a question. Sure, there are always work-arounds without it.
But, this is really a question of how to have a nice uniform model exposed in a UI. When I want to offer different types of breakpoints with different semantics for the same lexical entity, it is much more natural to work with before and after. Introducing new nodes to model everything with before might be possible as well, but then raises the question of how to communicate that in a UI, now to distinguish the two via source sections, etc.

[chumer]

@entlicher Do we have any plan to support this in the API? Could be a flag on Breakpoint, no?

[smarr]

@chumer if you look at my implementation, it uses the notion of SteppingLocation, which you already have to realize this 'as a flag' essentially.

[entlicher]

The suggested changes look good to me. I can add that to the APIs...

[entlicher]

Well, SteppingLocation is not in public APIs and I do not want to reveal that.
Breakpoint.Builder.haltBefore(boolean) should be sufficient IMHO, it'd correspond to SuspendedEvent.isHaltedBefore(). It's true by default, breakpoint suspends after by setting it to false.

[smarr]

Not sure I understand, a halt after would be haltBefore(false)?
Seems to be a bit non-intuitive API to me. The boolean could mean various things, but I wouldn't guess that it is a halt-after.

[entlicher]

Agreed, but I'm not sure it's nice to have Breakpoint.Builder.haltAfter(boolean), but SuspendedEvent.isHaltedBefore(). We'd need to rename it to SuspendedEvent.isHaltedAfter(). Maybe it's better to rename it...

[entlicher]

Thus, it's there: f048ca0
I've introduced a public enum SuspendAnchor instead of a boolean before/after.

[smarr]

Great, thanks! Will try to give it a spin next week.