A terminating line break has not been required in wfDebug() since 2014,
however no migration was done. Some of these line breaks found their way
into LoggerInterface::debug() calls, where they mess up the formatting
of the debug log.
So, remove terminating line breaks from wfDebug() and
LoggerInterface::debug() calls.
Also:
* Fix the stripping of leading line breaks from the log header emitted
by Setup.php. This feature, accidentally broken in 2014, allows
requests to be distinguished in the log file.
* Avoid using the global variable $self.
* Move the logging of the client IP back to Setup.php. It was moved to
WebRequest in the hopes that it would not always be needed, however
$wgRequest->getIP() is now called unconditionally a few lines up in
Setup.php. This means that it is put in its proper place after the
"start request" message.
* Wrap the log header code in a closure so that variables like $name do
not leak into global scope.
* In Linker.php, remove a few instances of an unnecessary second
parameter to wfDebug().
Change-Id: I96651d3044a95b9d210b51cb8368edc76bebbb9e
This allows us to remove many suppressions for phan false positives.
Bug: T231636
Depends-On: I82a279e1f7b0fdefd3bb712e46c7d0665429d065
Change-Id: I5c251e9584a1ae9fb1577afcafb5001e0dcd41c7
( $var & 1 ) is either 0 or 1, which can be used as a boolean value.
The main advantage of this is that there is no confusion with the
operator precedence. In `$var & 1 !== 1` the `!==` is executed first,
effectively turning it into `$var & 0`. This always succeeds.
Change-Id: I53c81a3891d42b2660eefc311f1f0f2523104894
This code is functionally identical, but less error prone (not so easy
to forget or mix these numerical indexes).
This patch happens to touch the Parser, which might be a bit scary. We
can remove this file from this patch if you prefer.
Change-Id: I8cbe3a9a6725d1c42b86e67678c1af15fbc5961a
Whitelist the remaining usages of assert(), and reinstate the PHPCS sniff
that forbids usage of it. Add FIXME comments as well, so any casual readers
of the code will not think that the disabling and usage is intentional.
Change-Id: I7cabe715c0e6aa6a9ef3ffe5657f3de7fd8e662b
Now, instead of "if your changed paragraphs are larger than 10Kb, you're
screwed":
* Instead of relying on overall length, estimate complexity after splitting to words
and taking any equal head and tail out of equation.
* Estimate based on words changed, which better reflects the actual complexity
of generating a diff.
* New limit is determined scientifically, i.e. "above that number XDebug starts
complaining about recursion limits reached in Vagrant".
Caveat: if new limits are hit, the consequences are more widespread as all adjacent
changed paragraphs are displayed without word level diffs, as opposed to only the
paragraph that's too long being affected. However, the new limit is much higher and
in wikitext you're supposed to put empty lines between paragraphs anyway, negating
this problem.
Bug: T128697
Change-Id: I4e91c7c40f5afdd116b847a859b8517522302489
