Page MenuHomePhabricator

Fix PhutilTypeSpec's regex handling for PHP 8
ClosedPublic

Authored by jrtc27 on Jan 11 2021, 2:04 AM.
Tags
None
Referenced Files
F19508808: D21499.id51176.diff
Sat, Jan 10, 10:47 AM
F19508807: D21499.id51170.diff
Sat, Jan 10, 10:47 AM
F19508806: D21499.id.diff
Sat, Jan 10, 10:47 AM
F18810994: D21499.diff
Oct 20 2025, 12:29 AM
F18782106: D21499.id.diff
Oct 13 2025, 12:37 AM
F18779450: D21499.id51170.diff
Oct 11 2025, 2:02 PM
F18653940: D21499.diff
Sep 21 2025, 10:40 PM
F18629670: D21499.diff
Sep 16 2025, 9:34 AM
Subscribers

Details

Summary

In previous versions, passing the wrong type to preg_match would give a
warning that could be suppressed by @ and caught by set_error_handler,
but as of PHP 8 this raises a TypeError and so remains uncaught. Thus
check up-front whether the provided value is a string.

This fixes linting arc itself when run with PHP 8, as includes and
excludes use "optional regex | list<regex>", so would previously try to
pass an array to preg_match for the first alternative and die.

Test Plan

Ran arc lint

Diff Detail

Repository
rARC Arcanist
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

preg_match() in all modern versions of PHP seems to be willing to accept an object with __toString() as the first parameter:

https://3v4l.org/KEAdq

...but I think it's correct to interpret the PhutilTypeSpec "regex" value as "a genuine string, exactly", particularly given how aggressively interesting PHP's __toString() is (see D20139) -- although it looks like this was finally fixed in PHP 7.4:

https://3v4l.org/me5Zf

I'm quite certain we never pass string-objects to preg_match(), and am happy to fix it when it breaks if I'm wrong.

This revision is now accepted and ready to land.Jan 11 2021, 3:38 AM