The functions returning null or the class property is set explict null.
Some function should not accept null or return null.
Found by phan strict checks
Change-Id: Ie50f23249282cdb18caa332f562a3945a58d86ff
This avoids mismatches between the language in the message cache and the
language converter used for content language.
Bug: T292239
Change-Id: I1f0ca70b184362a783d164658b3867e00a306591
The functions returning null or the class property is set explict null
Found by phan strict checks
Change-Id: I4a271093fb6526564d8083a08249c64cb21f2453
This replaces references to DefaultSettings with
references to config-schema.yaml where appropriate.
NOTE: this does not yet change Setup.php. DefaultSettings.php
remains intact and is still being used.
NOTE: this does not remove usages in the installer, see I5d8843a1062fbf
for that.
Bug: T300129
Change-Id: Ie6152cf510c3be61bc22167ca6d90dfc28910a45
LinkBatch::getPageIdentities() returns PageIdentityValues, which
are ProperPageIdentities. Indicate this in the return type
documentation to avoid phan complaints.
Change-Id: I461f2964aa9b4178d41e6071763e016b207c77d5
It is quite rare that a notice like this is best fixed so close to
the caller. More often than not, low-level code like this doesn't
have a reasonable way to handle it and it's a genuine issue but one
that a higher-level should prevent instead.
In this case though it seems fair to handle here because an empty
string is actually, according to most l10n-related classes, a valid
message key. It can't exist, but it is a valid key.
See also MessageCache::get() which does not consider it an error and
similarly returns false. That method never calls normalizeKey with
an empty string though. The error came from ApiQueryAllMessages.
I don't think it should be ApiQueryAllMessages's concern to normalize
this key or otherwise hardcode its non-existence over there.
Bug: T300792
Change-Id: I8a8eed66704862bb3a645ef5941a5264e65bde4c
Don't catch and discard exceptions from the RequestTimeout library,
except when the exception is properly handled and the code seems to be
trying to wrap things up.
In most cases the exception is rethrown. Ideally it should instead be
done by narrowing the catch, and this was feasible in a few cases. But
sometimes the exception being caught is an instance of the base class
(notably DateTime::__construct()). Often Exception is the root of the
hierarchy of exceptions being thrown and so is the obvious catch-all.
Notes on specific callers:
* In the case of ResourceLoader::respond(), exceptions were caught for API
correctness, but processing continued. I added an outer try block for
timeout handling so that termination would be more prompt.
* In LCStoreCDB the Exception being caught was Cdb\Exception not
\Exception. I added an alias to avoid confusion.
* In ImageGallery I added a special exception class.
* In Message::__toString() the rationale for catching disappears
in PHP 7.4.0+, so I added a PHP version check.
* In PoolCounterRedis, let the shutdown function do its thing, but
rethrow the exception for logging.
Change-Id: I4c3770b9efc76a1ce42ed9f59329c36de04d657c
* In LinkBatch::addObj(), reject interwiki links with a warning.
Otherwise the link is added to the batch by ns/title and later
reconstructed as if it were a local link without an interwiki
prefix.
* In CommentParser, treat interwiki links as always good, don't defer
the existence check.
* In LinkBatch, inject a LoggerInstance instead of calling LoggerFactory
in four places.
* Add a regression test, and some general tests for known links.
Bug: T300311
Change-Id: I0e5825eb48a6ba2932aea69a4d0fff3439c50ff5
When the called function has a doc of int, it should be cast to be
explicit here.
Also cast for arithmetic operations to be explicit about the number
Change-Id: I905b78dfb66e66443e0e3203488bab5b548db543
These are needed PageStoreRecord::REQUIRED_FIELDS and that's why putting
PageStore on top of LinkCache caused a lot of increase in db reads.
Bug: T297669
Change-Id: If77c2f9879d7bae71eb59944efd8b3798d16aa46
The code that was previously in LinkCache::getGoodLinkRow
may return a cached row object (either from the in-process
cache, or memcached). In some cases, this caused
LinkCache::addGoodLinkObjFromRow to throw, because a field
was missing (although the field is missing only from
the cached copy, not from the database).
To avoid this, try to invalidate the cache
in LinkCache::getGoodLinkRow and retry, before
letting the exception propagate.
Bug: T205349
Change-Id: Ie9e90bf32964047c1831f575cc260d7d62e9e848
The context is already called, just reuse it.
This avoids unstub of $wgLang in ParserOptions constructor
Change-Id: I3ac6abf6237db7c1c09740c1fec1224779e86888
LinkCache::addGoodLinkObj was hard deprecated.
Use addGoodLinkObjFromRow() instead. PHPUnit tests
must use LinkCacheTestTrait::addGoodLinkObject().
Bug: T284955
Change-Id: I0c22be2f00e6d6d4ba6dd1511c5385cad55e8ff7
addGoodLinkObj() has many optional arguments, but omitting them actually
means corrupting the cache.
Nearly all existing callers are in tests.
So LinkCacheTestTrait::addGoodLinkObject() was created only
for testing. It is better to have this method in the
trait, because building the row directly in each test
would make these tests brittle against schema changes.
The only usage in WMF production code was in WikiPage and has been
fixed.
Bug: T284955
Change-Id: I03a2bd9ed64fcc0281ee29a286c8db395a9e03d9
This helps phan to detect unreachable code and also impossible types
after the functions.
It helps phan to avoid false positives for array keys
when the keys are checked before
Bug: T240141
Change-Id: I895f70e82b3053a46cd44135b15437e6f82a07b2
