I would like to do this, but not just for tracing. I am intending to add filtering based on either a list of directory prefixes, or a list of namespaces.

With this filter enabled, this would act for tracing, stacktraces, code coverage, and perhaps also profiling (the latter is trickier, as it currently collates times from different functions into one blob).

That's great. I'm not really able to contribute to the code, but can offer testing support if you need it.

Can't wait for this one! It would drastically speed up my current functional testing with coverage report.

By the way, to make gathering of coverage easier in functional testing context (like JaCoCo) it would help if there were an option to activate code coverage for any request without the need to call to xdebug_start_coverage(). I did a patch to PHP to call those function for me automatically and save the report in a compatible format with PHPUnit tool to merge report but it is very dirty and the lack of blacklist/whitelist in xdebug make the all process slow...

Progress on leveraging this for php-code-coverage (and PHPUnit) is tracked at https://github.com/sebastianbergmann/php-code-coverage/issues/514

I recently made a commit to implement filters in a basic way. This
is by no means complete (or even working properly), but it gives a hint
of how this API could work.

The branch is: https://github.com/derickr/xdebug/tree/issue1059-filter
The commit is: https://github.com/derickr/xdebug/commit/db9e1a8d841a8837400d733a60db63f4d0f26b5f

Currently, the API for this is a single function:

proto void xdebug_set_filter(int group, int type, array filters)

The group is either one of XDEBUG_FILTER_TRACING, XDEBUG_FILTER_PROFILER, or
XDEBUG_FILTER_CODE_COVERAGE. You need to call xdebug_set_filter for each of
the three groups if you want to set up a filter for all of them.

The type is one of XDEBUG_PATH_WHITELIST, XDEBUG_PATH_BLACKLIST,
XDEBUG_NAMESPACE_WHITELIST, or XDEBUG_NAMESPACE_BLACKLIST.
The PATH variants operate prefix filters on the filepath of the
function/method's location and the NAMESPACE variants operate as a prefix
filter on the classname only, to white list non-object functions, you can use
the (empty) string ''.

Right now, if the filter finds a specific frame as "filtered out", it does
not filter out calls made from this function - they would show up as normal.
Is it worth changing that?

I would say yes to filtering cascades to child calls.

But each call would need to check the appropriate list.

So, if we reach a call that would be filtered out by the blacklist, it is filtered out.

Any calls that are subsequently made would be checked against the whitelist and if appropriate, filtered in.

And then you would look at the blacklist to filter out any further child calls.

etc.

Right now, you can't set both a black list or a white list. It's going to one of each. Remember that it costs time to check against these lists as well. I have to choose upon function call whether this function matches the blacklist or whitelist and act accordingly. And I'm inclined to make the filters cascading.

I can't make out the exact meaning of "you can't set both a black list or a white list. It's going to one of each.". Does this mean you can only set a blacklist OR a whitelist?

The main issue I would have with the filters cascading is that, for example, using a framework like Laravel, the code I've written is called upon by Laravel, not the other way around. Laravel sets up the routes, gathers all the data before calling my controllers. The controllers interact with Laravel's Eloquent ORM which in turn calls upon my models, observers, views and presenters. All VERY interleaved. If I excluded ./vendor, pretty much the second line of executed code would be within either composer's autoload or Laravel's framework.

As for checking against the list on each call, can you not add a semaphore to the file upon loading, indicating that the contents is filtered in or out? That way, the list has already been processed and it is a (hopefully) simple semaphore check to report the call? (I am not an expert here, so I may be WILDLY out).

Maybe it would be a good idea if you could demonstrate tracing of a Laravel based application but without reporting any of the Laravel calls.

Making the filter cascading looks weird to me.

The common use case for code coverage filtering is to filter out the vendor folder, keeping only your own code.
And we can have out own code being called from code living in vendors (the framework for instance).

I won't be able to actually experiment with the current state of the implementation until next week, but on first glance the API looks okay to me.

PHPUnit used to support both whitelisting and blacklisting for code coverage filtering. By default it used to use a blacklist and when a whitelist was configured it would use the whitelist but not the blacklist. This blacklist XOR whitelist usage makes sense to me. If it were up to me, though, I would not bother adding blacklist support to Xdebug. What I need from PHPUnit's perspective, whitelisting, is there and I will use that.

I am not sure that I understand the discussion about cascading correctly. How I expect the filtering for code coverage to work is this: when I put one directory on the whitelist then only files that are in/under that directory must show up in the code coverage data. It does not matter where code in that files is called from.

Has this feature had any movement?

Closed in Xdebug master, for Xdebug 2.6.0 (and beta1).