Ideally we'd just have composer.json require UtfNormal so we'd know
where it is and have an autoloader to load it for us, but that seems to
not be done in the world of MediaWiki extensions.
Previously we had been taking paths to the two data files from UtfNormal
and loading them into a stub class, but phan has started complaining
about the definition of the stub class colliding with the real UtfNormal.
So let's try loading the real UtfNormal\Validator and its data files.
Hopefully this continues to not try to pull in any other files via the
nonexistent autoloader.
Change-Id: I93baf20f0eef1892685e272793b4f99236e8c905
As documented, string.gub( 'foo', '%a', '%1' ) should raise an invalid
capture index error because there is no capture with index 1 in the
pattern. But in fact it treats %1 as %0 in this situation. The ustring
library should match this behavior.
This patch also adds some tests for the behavior of gsub with table and
function replacements when the pattern does have captures.
Bug: T207623
Change-Id: Ie3e6c2eafa4a05989815c62c7037167642581751
Its a command line script, so echoing is not an XSS. It can
do malicious things if given a malicious command line argument,
but that is by design
The last remaining phan-taint-check warning is due to a bug
in the plugin.
Bug: T202380
Change-Id: I19a07f741980a7e4d5e8458395c67523d240d221
If the replacement table or function results in a value that isn't a
string or number (or nil), string.gsub raises an error. Have ustring
raise the same error.
Bug: T195326
Change-Id: Ic36f9f5d7adc0c14e7a4a94d3747335107acd8b6
normalization-data.lua is updated to Unicode 8.0.0 (libicu57).
charsets.lua is updated to match the character classes used by PCRE 8.35,
which seems to be Unicode 6.3.0.
upper.lua and lower.lua are still based on whatever ancient version of
Unicode is used by mb_strtoupper and mb_strtolower in HHVM 3.18.6.
Bug: T177498
Change-Id: I00b471176e1fd21123c22d187ff222928819e459
