[wp-trac] [WordPress Trac] #46152: Add PHPCompatibility checks to test suite

[WordPress Trac]

#46152: Add PHPCompatibility checks to test suite
-------------------------------------+-------------------------------
 Reporter:  desrosj                  |       Owner:  (none)
     Type:  task (blessed)           |      Status:  new
 Priority:  normal                   |   Milestone:  5.3
Component:  Build/Test Tools         |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  coding-standards
-------------------------------------+-------------------------------
Changes (by desrosj):

 * keywords:  has-patch => has-patch needs-testing
 * version:   => trunk
 * type:  feature request => task (blessed)
 * milestone:  Future Release => 5.3


Comment:

 I'm moving this to 5.3 because I think there is value having this in Core
 today for a few reasons.

 1. It helps with the effort to add PHP 7.4 support.
 1. It makes it easier for contributors to test their code for
 compatibility issues.

 Using @jrf's suggestions, I am uploading a new patch. I went through the
 list of warnings and errors and accounted for a large number of them. I
 purposefully did not address or add exclusion rules for some issues that I
 know are being addressed elsewhere as a part of the PHP7.4 support effort
 (such as `func_get_arg` warnings being addressed in #47678). This includes
 the ones in external libraries such as Requests and SimplePie.

 - The patch adds a new job to the Travis build that is allowed to fail
 (for now).
 - I left out the `@php ...` suggestion because this change should also be
 made to the other `phpcs`/`phpcbf` scripts. They can all be addressed at
 once.
 - I chose to supply an upper PHP limit of `7.4`. This ensures the build
 will not start failing randomly as new versions of PHP are accounted for
 in the tests. This actually may not be a concern depending on how the
 `PHPCompatibility/PHPCompatibilityWP` package is versioned. But, having
 the upper limit be an intentional version bump that is applied clearly
 shows what Core's version support goal is and could prevent the build from
 randomly starting to fail when the job is removed from the
 `allow_failures` list.
 - I opted for inline ignore statements (with a few exceptions) instead of
 exclusion rules in most cases to match the approach used for the coding
 standards ruleset.

 I have a test branch set up on my fork that [https://travis-ci.org/desrosj
 /wordpress-develop/builds/586129264 shows the new Travis build]. More
 specifically, [https://travis-ci.org/desrosj/wordpress-
 develop/jobs/586129277 this is the added job].

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/46152#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform