The $text is constant and that means, the length of $text is also
constant, store it in a local var is easy than.
Change-Id: I9631b862f40eef7f8b18559ffd474a0037077d18
I am not sure, but this looks wrong, because it adds the type to the
array and not the child.
This method is unused in core and wmf extensions, maybe
removing/deprecating is a better idea, but I am not sure, if that is
possible.
I have only see this possible error, while looking through the
preprocessor.
Change-Id: I5b7492d455989a8a3e71b5db6d31091b986c502a
With 1.20wmf2 we get a tracking category with all the problem pages,
seeing the limit for a page is a helpful information than
Change-Id: I1916e5fa6de06b923a01cf1f0ca9362287a9fd70
I have only add things and not change the current error strings to
messages, because bug 21521 is WONTFIX
Change of Preprocessor_HipHop.php is not tested
Change-Id: I7a7243b8ba010dbb395bdbbb3e00e3217088038e
* Set EnableHipHopSyntax=true to enable string and integer type hints. I gave the file a .hphp extension to avoid false alarms in syntax checking scripts.
* Made sure almost all the local variables in preprocessToObj() have a specific type, instead of being variants. This is useful for integers, but has the largest impact for objects, since dynamic method calls can be avoided.
* Stopped using extract() since it forces all local variables to be variants, and adds some hashtable initialisation overhead.
* Found a way to cast a variant to a specific object class, by abusing argument type hinting. The method does not require special syntax; it is harmless in Zend PHP.
* Wrapped various internal function calls with type casts. strspn() and substr() need to be wrapped with intval() and strval() respectively, since they return a variant to support special error return values. HipHop isn't smart enough to know whether the error case will be triggered.
* Replaced most instances of double-equals with triple-equals. Profiling indicates that this makes a very large difference when comparing strings, much more so than in Zend.
