Hi Brad,

right now, as you probably know, the "Continuation commands" (https://xdebug.org/docs-dbgp.php#continuation-commands) don't provide this information. I believe it would not be a great idea to change the response value. Firstly, it changes ancient and stable behaviour, and secondly, there can literally be thousands of values in there, as it's quite possible to jump over a function call which itself calls a lot of functions.

However, it might be possible to use DBGp notifications (https://xdebug.org/docs-dbgp.php#notifications) for this. For example, by adding a new notification "function_return_value" (better name to be picked), which — for each finished function — would generate a notice containing the function/method name, file/line combination of the return, and the return value. I would suggest that this feature should be specifically enabled through a "feature_set" (https://xdebug.org/docs-dbgp.php#feature-names), for example: "notify_return_values". It could have multiple values:

• "always", for all return values
• "stepped_over", for all values when "step_over" was used as a continuation command
• "never", for never returning these notifications (the default)

Then IDEs can opt into receiving these "return_value" notifications by setting "feature_set -n notify_ok -v 1" and "feature_set -n notify_return_values -v stepped_over".

I would consider adding this, if multiple IDEs would implement this. I would specifically like PhpStorm to implement this as well, as this tends to be the largest consumer of the DBGp protocol.

cheers,
Derick

Firstly, it changes ancient and stable behaviour, and secondly, there can literally be thousands of values in there, as it's quite possible to jump over a function call which itself calls a lot of functions.

I was actually envisioning this functionality to only report the "nearest" function return, i.e. the one within the same context/scope/(?) as before the step. To use my example above, you'd only see the return for test1() and test2(), not any function(s) called within them. I can't think of a solid use case where supplying every returned value within the entire chain of execution could be utilized in an IDE (without some weird, overly-complex UI).

As for your reluctance to alter a long-standing part of the API, I can absolutely see that. In fact, I had already read about the notifications functionality and had almost suggested that to begin with... hearing that's your preference leads me to agree as well.

• "stepped_over", for all values when "step_over" was used as a continuation command

Circling back to my comment above, can I suggest that the notification be formed in such a way that the consumer can easily pick out the "nearest" return in the chain? I have a feeling this will be the most (if not only) desired value, so having a simple, deterministic way of picking out that specific value would probably aid in getting IDEs/etc. to buy into making changes to use this data.

I would consider adding this, if multiple IDEs would implement this.

Great! What, if anything, can I do to help this feature request along? Create an issue in PhpStorm's YouTrack to describe the proposed change and see if they would at least confirm wanting it for some future version?

I'd offer to help with a pull request on Github... but I'll admit, after stepping around the Xdebug code in VS for about 1/2 hour, I wasn't liking my chances of understanding everything that's going on and how to tackle capturing the Zend engine returning values from PHP function calls.

I would specifically like PhpStorm to implement this as well

As would I... since that happens to be the only IDE I use in conjunction with Xdebug =).

Firstly, it changes ancient and stable behaviour, and secondly, there can literally be thousands of values in there, as it's quite possible to jump over a function call which itself calls a lot of functions.

I was actually envisioning this functionality to only report the "nearest" function return, i.e. the one within the same context/scope/(?) as before the step.

That makes a little bit more sense, however, that's implementation wise not easy as I would never know what the "nearest" would be while running the code. The implementation would still need to capture all the return values (and convert them to XML/a string), and only send them along with the result of the Continuation Command.

Circling back to my comment above, can I suggest that the notification be formed in such a way that the consumer can easily pick out the "nearest" return in the chain? I have a feeling this will be the most (if not only) desired value, so having a simple, deterministic way of picking out that specific value would probably aid in getting IDEs/etc. to buy into making changes to use this data.

The IDE would just have to show the last one that it received.

Great! What, if anything, can I do to help this feature request along? Create an issue in PhpStorm's YouTrack to describe the proposed change and see if they would at least confirm wanting it for some future version?

Yes, I think that would be helpful.

I'd offer to help with a pull request on Github... but I'll admit, after stepping around the Xdebug code in VS for about 1/2 hour, I wasn't liking my chances of understanding everything that's going on and how to tackle capturing the Zend engine returning values from PHP function calls.

Xdebug already captures the return value for trace files:
https://github.com/xdebug/xdebug/blob/master/xdebug.c#L1887-L1900

Getting them into a notification (or "break state") would be the trickier part.

cheers,
Derick

Is this issue still relevant to you? We sort of dropped the ball on it.

I'm closing this out, as there was no feedback for two months asking whether this was still relevant.