MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001591XdebugFeature/Change requestpublic2018-12-01 11:342018-12-03 10:27
ReporterBradG 
Assigned Toderick 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0001591: Augment step_* responses to include returned values
DescriptionIf a function call is stepped over (or a `return' statement is stepped over while inside a function), include information about the returned value in the <response> object. Ideally, this information would include: returning function's name, type of returned value, and the returned value.

A use case for this data would be IDEs displaying return values when stepping over function calls (or out of a function). This is especially useful when the return value gets consumed inside of a control structure and isn't stored in a variable. For example:

<?php
if( func1() && func2() )
    echo "Func1 and func2 good!"


As it stands now, you'd have to step into func1() and potentially func2(), examine the value it's going to return before it does so, and then step out of the function. And if you're stepping too quickly while debugging the above code, you'll simply jump over the if() statement and have no way of easily determining which function returned a false value.
TagsNo tags attached.
Operating SystemN/A
PHP Version7.2.10-7.2.14
Attached Files

- Relationships

-  Notes
(0004734)
derick (administrator)
2018-12-02 18:43

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
(0004740)
BradG (reporter)
2018-12-03 01:09

> 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 =).
(0004741)
derick (administrator)
2018-12-03 10:27

> > 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

- Issue History
Date Modified Username Field Change
2018-12-01 11:34 BradG New Issue
2018-12-02 18:43 derick Note Added: 0004734
2018-12-02 18:43 derick Assigned To => derick
2018-12-02 18:43 derick Status new => feedback
2018-12-03 01:09 BradG Note Added: 0004740
2018-12-03 01:09 BradG Status feedback => assigned
2018-12-03 10:27 derick Note Added: 0004741
2018-12-03 10:27 derick Status assigned => acknowledged


Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker