Scalar casts are still allowed (for now), because there's a huge amount
of false positives. Ditto for invalid array offsets.
Thoughts about the rest: luckily, many false positives with array offsets
have gone. Moreover, since *Internal issues are suppressed in the base
config, we can remove inline suppressions.
Unfortunately, there are a couple of new issues about array additions
with only false positives, because apparently they don't take
branches into account.
Change-Id: I5a3913c6e762f77bfdae55051a395fae95d1f841
Repeating the variable name doesn't do anything. Documentation
generators don't need it. It's more stuff to read that doesn't add new
information. And it can become outdated.
Note there are two types of @var docs. When used inline (and not on a
class property) the variable name is needed.
Change-Id: If5a520405efacd8cefd90b878c999b842b91ac61
Reduce the cost of calling LegacyLogger::debug() when there is no debug
log enabled (the normal production case) from 0.8µs to 0.2µs, measured
locally, by duplicating some of the logic from log() and shouldEmit() to
derive a constant "minimum level".
I also introduced constants for the integers, to avoid unnecessary
lookups in self::$levelMapping, and I introduced $this->isDB, to avoid a
hashtable lookup in log(). I fixed a typo in a comment, and removed
"@return null", which was confusing PHPStorm.
Change-Id: I9fc37b8062ff22f85feda9a05821e3d8c9688519
Some of the errors are suppressed because they're phan false positives.
The idea behind this is that they'll be fixed in a future version of
phan, and we'll just have to remove the suppressions.
Note: I'm disabling UnusedPluginSuppression so that we can start suppressing
issues even if they're still disabled. The sniff should be re-enabled
as soon as we upgrade phan.
Bug: T231636
Change-Id: I0f7fa06a9e03fbb86c7a5eb6e50a850bb258a7f7
This broke after e0cc49ce39, due to the field 'master'
being removed from the log context. The LegacyLogger logic
forwarding these messages to MWDebug (for the debug toolbar)
however, was dependant on.
Users of debug toolbar experienced a silent failure because the
logic in question is very tolerant of missing fields. This is
because it uses those fields to distinguish the 'sql' messages
from channel=DBQuery from other messages in the same channel.
Making that less fragile is outside the scope of this commit.
This commit:
* Restore the basic functionality by making sure MWDebug::query()
gets called again for DBQuery messages.
* Remove the code relating to the 'master' field as this no longer
exists in RDBMS. It also wasn't used anywhere (to be used,
it would need to be read by mediawiki.debug/debug.js).
* Remove unexpanded "{method}" and "{runtime}" noise in the debug
toolbar text. This was introduced by he conversion to PSR-3
logging.. These fields are already rendered separately by
the toolbar and should not be part of the "SQL" column.
To do this, we need to log the $sql bit as its own key, so
I've made this a context field as well.
* Reduce the condition logic in LegacyLogger to only looking for
'DBQuery' and 'sql'. This way, if it breaks again it will
still call the logic within and emit E_NOTICE instead, which
would help detect the issue (and still fallback to at least
showing the queries). Unlike before this commit where it took
quite some time to figure out why it wasn't working.
* The above fixes still weren't enough to get queries to show
up in the Debug toolbar for me. Turns out, this was because
my local setup (mediawiki-docker-dev) uses a master-replica
set up. The setup doesn't use any custom LBFactory config,
just plain $wgDBservers. The logic for turning these plain
settings into LBFactory (in MWLBFactory.php) does kick in,
and does run (unlike if I had custom wgLBFactoryConf).
But, the DBO_DEBUG flag didn't make it through because of
the += operator preferring any pre-existing value my setup
has, which is just `DBO_DEFAULT`.
Merging 'flags' keys seems unsafe in general, but adding
DBO_DEBUG based on $wgDebugDumpSql seems innocent and doesn't
affect other behaviour (it's a case of DWIM).
Bug: T231742
Change-Id: I122bb1a65620a7ae4e1943136c975b63524a5111
This is for classes with a single undeclared property - aside from
BlockManager: I3f51fd3579514b83b567dfe20926df2f0930dc85 removed the
declaration of $permissionManager without actually removing all uses.
Change-Id: Ic2a95f77071312041be6e0633ea9b5325e98de42
The code was checking for `Exception` to decide whether to produce traces,
so it wasn't providing them for PHP 7's new Errors. The code itself
works fine with any Throwable.
We have to keep parallel checks for Exception too for the time being,
because HHVM as used in Wikimedia production doesn't have Throwable.
Bug: T187147
Change-Id: Iec8a6718beb7ec09e45e332ee5762d0644ce17ab
In the array 'loggers' the key '@default' is assumed to be present,
hence be sure it is defined: this is the system default for MediaWiki,
it can be overwritten if desired.
This default php://stderr with level ERROR is inspired from Monolog’s
own default, which is php://stderr with level DEBUG: this is similar
but less violent for the average MediaWiki sysadmin.
Bug: T196906
Change-Id: Id74083fc20ddf906c40e6d149095e8ade4c68572
Introduce a new handler, similar to SyslogHandler, that will be used to
replace udp2log. The main feature of the handler is being able to vary
the 'application name' with each record's channel. This way the channel
can be reconstructed later, e.g. when writing to plaintext files.
See also an overview of the plan here:
https://phabricator.wikimedia.org/T205856#4957430
Bug: T126989
Change-Id: I0c040825b31cd70f197dc8c1d406a103dc0ed1d1
Basically turning Mediawiki to MediaWiki as all other classes exist
in that namespace
Bug: T217128
Change-Id: I95039a1a54c9900a2f2414b5a6ccce5fb6e5e612
When a unit test fails it is possible, perhaps even likely in some
cases, that some code that was run logged useful information about
how that failure came to be.
Help people out, tell them what happened!
Change-Id: I30bbc31799a65024868678d052fec9aafacc1aff
This formatter extends LogstashFormatter to prefix records with "cee token"
used for syslog and JSON structured logging. See also related task for more
context.
Bug: T211124
Change-Id: I3cdeb4c666f54039b5e8ecc67bd4937220333526
In Monolog\Logger (Logger.php), the logger levels are constants (interger values).
Logger::DEBUG is a constant (int) with value 100 which depicts that error logging
level. Datatype of these values; DEBUG, INFO, WARNING, etc are all integers not
strings.
Change-Id: I1cc67381bc64800241f5f9b7232ffe5419388d8a
Follows-up 81e8d7af41 and e861191b2c.
When using $wgShowDebug, $wgDebugComments, or $wgDebugLogFile
locally, or when using the 'log' attribute with X-Wikimedia-Debug,
all channels should be enabled and logged. But, the DBQuery logs
are currently going nowhere.
The code for MWDebug::query() is intercepting it, even if
$wgDebugToolbar is not enabled.
And after that, the code for wfLogDBError was intercepting it,
again, even if $wgDBerrorLog is not enabled.
Bug: T202764
Change-Id: I710c26a9e9c30fea20975d1bc24e1f0af077c2ad
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
Change-Id: Idcec077ef3fdf029b632cceafd0150851ad723e3
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
Deprecate the unnamespaced version and move it to includes/compat.
Bug: T147167
Depends-On: I39c805bfb98b32f32f3d0dc1eee9e823afe1c21a
Change-Id: I3780c7adf51683f3f7adb35a88f9a25a0a2e2530
phpdbg is a gdb-style debugger for PHP that is run from the command
line. However, it has a different PHP_SAPI value, so it was impossible
to run maintenance scripts with it (until now).
To avoid having to check both PHP_SAPI values in a bunch of places,
introduce wfIsCLI() to easily check whether running from the
command-line or not.
We're (CI team) interested in generating code coverage with phpdbg
instead of xdebug, hence this patch.
Bug: T184043
Change-Id: Id1f994ca146d7858cd8bb6ab6cdbb7718ff524fb
Follows investigation from T172559, where we found that there is no explicit
way to find what script triggered particular error messages when the script
was run from the command-line (as opposed to a web request, where the
built-in WebProcessor adds fields like http_method and url).
Change-Id: Ia9641274a164137dcc30324578d750cc662976ee
In phpcs.xml rename renamed sniffs and add the failing sniffs,
because now the whole sniff is no longer excluded.
Change-Id: If5b0bd16028761abc2c47ace9e97d37ad14bb36f
Undo traces of a practice we carried over from past projects and
existing examples that is neither universal nor actively encouraged in
the MediaWiki codebase.
Bug: T139301
Change-Id: I5c9c89b72a45a44aa4264a5e57b003c1a86cdf6e
Co-Authored-By: Brad Jorsch <bjorsch@wikimedia.org>
eval.php previously set $wgDebugLogFile to /dev/stdout. This had the
following problems:
* It doesn't work if the maintenance script is executed via sudo, since
/dev/stdout is typically owned by the original user, so MW can't open
it. Using php://stdout worked on HHVM but not PHP.
* Setting $wgDebugLogFile has no effect if the wiki uses MonologSpi.
* Setting $wgDebugLogFile has no effect on channels configured with
$wgDebugLogGroups.
* stderr is a more appropriate place to send logging output.
* Writing to configuration variables is discouraged.
So, add ConsoleSpi, which is a very simple logging service provider
which sends all messages to stderr. This should be suitable for
debugging with eval.php or shell.php in WMF production or beta.
Change-Id: Ib0d6ce45e0cbecd58263fc4e360c63d4149acb3a
