Consider using dedicated PHP-Parser

[swissspidy]

The PHP function scanner in the upstream gettext library is a bit hacky and often buggy. See #96 for the latest issue.

For the JS function scanner we already use a proper parser (https://github.com/mck89/peast), so I figured we could try the same for the PHP equivalent.

https://github.com/nikic/PHP-Parser looks very promising, and usage is similar to the JS one. Unfortunately the current version requires PHP 7 to run. The previous version requires only PHP 5.5, but is unsupported and doesn't fully support parsing PHP 7.3 code.

Nevertheless, I want to give it a try. Perhaps forking the library and making it PHP 5.4 compatible is an option.

[drzraf]

1. From the sole PoV of extraction, it's clearly superior to rely upon a yacc-backed AST than the current FunctionsScanner.

2. But the behavior of String Audit: False-positive for different translator comments #96 does not seem like a bug but rather an assumption that translator comments always precede the i18n function call. Changing the underlying parser would not solve it by itself. (not sure after all)

3. PHP-Parser has a larger dependency chain. It automatically generates a parser file (much more opaque than oscarotero PhpFunctionsScanner btw) from a grammar. Although this is an infrequent process, outside the scope of wp-cli, it's worth noting that it still rely upon kmyacc-forked (custom fork, C-codebase, updated 2009).

4. Whether one parser is better or not than another, I believe that oscarotero intermediary library comes very useful since it encapsulates several parsers under the same API (Twig, PHP, VueJs, ...). I wouldn't be surprised that WordPress needs i18n far outside PHP in the next years (JS, react, ...). Having a diversity of language extractors under a common API is then very useful.

5. For having dug inside it, I do agree that oscarotero's interface (to manage callback functions) could be better and adding/changing extractors could be made easier.