* New operands i, v, w, f, t
* New operators =, !=, %
* Ignore "samples", which are basically unit tests embedded in rule
specifications
* Ignore the new "other" rules, which have an empty condition. It
doesn't really makes sense to parse them, since the empty condition
means special handling should be done in the caller, it is not
equivalent to an unconditional true or false.
* Trailing zero support requires that the input number be a string.
Documented this.
* Fixed some comments
* Added test cases for new features
Bug: 56931
Change-Id: I96986c0c664f785e75b0a4ced2ec9e37b72681c1
Fix almost all occurences of the following sniffs:
Generic.CodeAnalysis.UselessOverridingMethod.Found
Generic.Formatting.NoSpaceAfterCast.SpaceFound
Generic.Functions.FunctionCallArgumentSpacing.SpaceBeforeComma
Generic.Functions.OpeningFunctionBraceKernighanRitchie.BraceOnNewLine
Generic.PHP.LowerCaseConstant.Found
PSR2.Classes.PropertyDeclaration.ScopeMissing
PSR2.Files.EndFileNewline.TooMany
PSR2.Methods.MethodDeclaration.StaticBeforeVisibility
Change-Id: I96aacef5bafe5a2bca659744fba1380999cfc37d
Wrote a CLDR plural rule parser to replace the eval()-based one from
I58a9cdfe. It converts the infix notation of the XML files to a
sanitized RPN notation, referred to in external interfaces as the
"compiled" form. The RPN notation is cached and then executed by a
fast non-validating evaluator.
Timings for the largest rule in the XML file are ~1.2ms for
compilation and ~200us for execution.
Also:
* Lazy-load the plural rules when recache() requests them, instead of
loading them for every request.
* Language::convertPlural() needs integer keys, and CLDR only gives
string keys. The previous code was not mapping them so it didn't work
at all. I just mapped them in the order they appear in the XML file,
i.e. the first rule becomes MediaWiki's $pluralForm=0, the second
becomes $pluralForm=1, etc. Not sure if there is a more rigorous way
to do it.
Change-Id: I65ee788c1a8e5ee2ede2091990d86eb722749dd3
