| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Bug: T353458
Change-Id: If02cc9b1ff78e26c1cf8c91ee4695845eb133829
|
|
|
|
|
| |
Bug: T353458
Change-Id: Id3202c0c4f4a2043bf97b7caee081acab684155c
|
|
|
|
| |
Change-Id: I5629f91387f2ac453ee4341bfe4bba310bd52f03
|
|
|
|
|
| |
Bug: T357823
Change-Id: I1d07ff559f4607ba98bc834a1432e014f3ebdd35
|
|
|
|
|
|
|
|
| |
Bug: T166010
Co-Authored-By: Daimona Eaytoy <daimona.wiki@gmail.com>
Co-Authored-By: James Forrester <jforrester@wikimedia.org>
Co-Authored-By: Subramanya Sastry <ssastry@wikimedia.org>
Change-Id: I79b4e732c45095eedbaa80afa5eb7479b387ed8a
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I could not find any use outside of core, or even outside of this
class.
The class is instantiated a single time in core:
https://codesearch.wmcloud.org/search/?q=new%5CW%2BLinkHolderArray&files=%5C.php%24
This instance is not used anywhere else:
https://codesearch.wmcloud.org/search/?q=mLinkHolders&files=%5C.php%24
I would argue this doesn't really qualify as a breaking change. This
was always meant to be private.
Change-Id: I4c614dae1fe1d61c9cf8b7a03c37eb93fae33873
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
Just methods where adding "static" to the declaration was enough, I
didn't do anything with providers that used $this.
Initially by search and replace. There were many mistakes which I
found mostly by running the PHPStorm inspection which searches for
$this usage in a static method. Later I used the PHPStorm "make static"
action which avoids the more obvious mistakes.
Bug: T332865
Change-Id: I47ed6692945607dfa5c139d42edbd934fa4f3a36
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is moderately messy.
Process was principally:
* xargs rg --files-with-matches '^use Title;' | grep 'php$' | \
xargs -P 1 -n 1 sed -i -z 's/use Title;/use MediaWiki\\Title\\Title;/1'
* rg --files-without-match 'MediaWiki\\Title\\Title;' . | grep 'php$' | \
xargs rg --files-with-matches 'Title\b' | \
xargs -P 1 -n 1 sed -i -z 's/\nuse /\nuse MediaWiki\\Title\\Title;\nuse /1'
* composer fix
Then manual fix-ups for a few files that don't have any use statements.
Bug: T166010
Follows-Up: Ia5d8cb759dc3bc9e9bbe217d0fb109e2f8c4101a
Change-Id: If8fc9d0d95fc1a114021e282a706fc3e7da3524b
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These specific placeholders are meant to stay untouched in the test.
Because of this it technically doesn't matter if the namespace numbers
and link ids (from Parser::nextLinkID) are numeric. Still I find it
less confusing when the test setup reflects how the code actually
behaves. An IWLINK is identified by a single numeric id, and a LINK by
a namespace:numeric id pair.
This is split from Ie994059 to make it easier to review.
Change-Id: I1141de06eb3235d199a3dc02ef0a24d0d4fe1416
|
|
|
|
|
|
|
|
|
|
|
| |
These array keys are all meant to come from Parser::nextLinkID(). That
returns a positive integer. Let's please make the tests reflect what
the code actually does to reduce confusion.
I tried my best to come up with a mapping that still (possibly even
better) makes it obvious what's happening.
Change-Id: Ib5d5f6f48ddc8c066961ea0f36a922ae9f0c6f6c
|
|
|
|
|
|
|
|
|
|
| |
The first level in LinkHolderArray::$internals is indexed by numeric
namespace id. This must be a number. Let's please make the test
reflect what the code actually does.
Note the same mistake was already fixed before in I7e71ffc.
Change-Id: I14f717510a71adf8ea3f75e61ba844d93838f945
|
|
|
|
| |
Change-Id: I63fc731ca1dbaef6f215279ee0b1788e735783df
|
|
|
|
|
|
|
| |
We *know* this can never be anything but a Title object:
https://codesearch.wmflabs.org/search/?q=makeHolder
Change-Id: Id6de0df627f2aeda79c6483f12a6d500ccd7853f
|
|
Bug: T243747
Change-Id: I2c12cc76a9bf01eb527db3ea038e4adc59446cac
|