Babel: it-N, en-3, fr-1
Heh, depending on the main RequestContext isn't ideal... We could perhaps use an anonymous class implementing MessageLocalizer and proxying the call to wfMessage. And maybe do that conditionally, only when the main context isn't available. This, together with the fact that we only need to use the content language for the message, might be enough to fix (haven't tested).
Mon, Mar 30
Sat, Mar 28
Latest result with taint-check 3.0.1 (excluding roughly 120 DoubleEscaped warnings):
Personally, I just wasn't aware of that method. I can't tell whether it could break anything though.
Fortunately this was an easy fix. The code analyzing property access (e.g. $foo->bar) has a special case for when $foo is a stdClass: in this case, accessing a $foo->bar would transfer foo's taintedness to bar. However, the code doing that didn't check whether the LHS of -> is a variable, hence it tried to parse a variable from the LHS even in cases like Foo::myFunc( 'myParam' )->bar. In turn, this would create a bogus variable named $Foo which phan wouldn't recognize.
I'll make sure to prepare the (painful) backports for 1.33 and 1.34 as well, once the patch is reviewed/approved/merged on master.
Fri, Mar 27
Also reported at https://www.mediawiki.org/wiki/Topic:Vjdi1tkxzyyl9wbj
Meh, it's taint-check messing up with phan. I'll take a look tomorrowish... Also:
Thu, Mar 26
Ouch: https://integration.wikimedia.org/ci/job/mwext-php72-phan-docker/43938/console some are weird:
Closing in favour of T248630 for the remaining part.
See also T183174. I haven't checked whether that issue is now fixed.
Yeah, well, I think this could've been caused either by MW not setting the right expiry, or memcached not evicting the key.
So, things to consider here:
- The issue comes from taint-check, not phan itself. Hence, the mediawiki-tools-phan repo isn't playing any role here.
- Specifically, https://github.com/wikimedia/mediawiki-tools-phan/blob/master/src/config.php is NOT the file used by taint-check
- Taint-check runs in its own CI job, separated from the main phan job. It also uses a different version of phan (latest stable uses phan 1.3.2
- Phan 1.3.2 does have tests marked as export-ignore, but somehow that isn't working (?)
- Taint-check also uses its own config file, which does NOT exclude test files
- Additionally, PHP 7.2 is bugged, in that it throws a fatal ("Cannot use the final modifier on an abstract class") when tokenizing invalid code, even if that code isn't going to be executed. See phan issue #3407 and linked PHP bug report.
Tagging for 1.35, ideally we should get the script working and added to update.php before the release. Running the script on WMF wikis is not included per se, but de facto that's how we're gonna see if the script is bug-free.
Sat, Mar 21
The test contains: ip_in_range( '22.214.171.124', '0.0.0.0/0' ), which fails due to the range not being accepted.
Fri, Mar 20
FTR, note that phan already checks for this. However, many extensions don't run phan (and it's also never executed on tests), so it's a good idea to have a PHPCS sniff for this.
Thu, Mar 19
Wed, Mar 18
@eprodromou Is the CPT willing to participate as advisor, or is this task just for info/tracking?
Tue, Mar 17
Not because of PHP 7.4 :-[
Mon, Mar 16
Meh, I thought these test-only errors would have been spotted by the wmf-gate jobs. Sorry for the breakage :(
Sat, Mar 14
It doesn't seem a recent regression, see https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Wikibase/+blame/de5e309c258b121bf0626728d8d9a6fd2ab0c717/client/tests/phpunit/includes/ClientParserOutputDataUpdaterTest.php#170
Now it should be compatible. Can we enable PHP74 tests as voting?
I think this shouldn't be too hard. The DB rows is storing NS and text separately, so it's just a matter of choosing the right method to build the link. Since the AbuseFilterRightsLogFormatter doesn't handle links, it should probably reimplement some parent's method to do that (I haven't checked which one).
Fri, Mar 13
Thu, Mar 12
Wed, Mar 11
Tue, Mar 10
P.S. Memo: those caused-by lines are terrible. I should check why and fix.
From a very quick look, it may be caused by the 'parentheses' message not being escaped in formatRow. It's probably worth a try. (Note: I didn't check what's the effect of changing text() to escaped() on the params)
Mon, Mar 9
Note that, for future tasks, this list may be generated using maintenance/findDeprecated. The current version is incomplete and (at least for me) doesn't seem to be able to find hard deprecation, but there's a new version at https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/566537/. It should probably be put in a separated library, but you can git review -d and use it locally. For hard deprecations, it's
php maintenance/findDeprecated/findDeprecated.php | grep "\+"
Superseded by / subtask of T240307?
Currently, we have several classes representing blocks (DatabaseBlock, SystemBlock, ...), all based on the AbstractBlock class, which doesn't involve the Database at all. Hence, I think this task should be updated. We could:
Sun, Mar 8
This was done.
Sat, Mar 7
I did something similar at https://gerrit.wikimedia.org/r/#/c/mediawiki/libs/IPUtils/+/522989/, but adding another method instead.