Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I73fb416573f5af600e529d224b5beb5d2e3d27d3
Fix two problems that made it difficult to convert between Message
and MessageValue, or to write code that could accept both of them,
as exemplified by the StatusValue class:
* Implement a common interface
* Use the same internal format for message parameters
While these changes should be compatible with most of existing code,
where the authors were courteous enough to simply call methods such
as Message::numParam() and not look inside the values they return,
it is potentially a breaking change for anything that depended on
the formatted params being arrays or accessed their keys.
Example patches: https://gerrit.wikimedia.org/r/q/topic:message-param
Notable changes:
* Message and MessageValue now both implement MessageSpecifier
(only Message implemented it before).
* Message::numParam() and other static methods for encoding params
now return MessageParam objects, instead of special arrays.
Use these MessageParam objects internally in Message.
* Narrow down the return type of MessageSpecifier::getParams() (it
was just `array`, allowing any type in the array). Narrow down the
types for Message::params() and MessageValue::params() to match.
* Deprecate MediaWiki\Message\Converter. As a replacement add
MessageValue::newFromSpecifier(), which is analogous to
Message::newFromSpecifier(), but without weird legacy edge cases.
* Make StatusValue::getMessages() return MessageValues. Remove code
that converted between Message and MessageValue, no longer needed.
* Update many type declarations and comments to use MessageSpecifier
instead of MessageValue, as well as a couple of tests that depended
on implementation details.
Bug: T358779
Change-Id: I625a48a6ecd3fad5c2ed76b23343a0fef91e1b83
php documentation:
If the size of post data is greater than post_max_size, the $_POST and
$_FILES superglobals are empty.
When the action= and format= are not in the GET data,
the help page is returned in html, breaking the clients expected format.
Return api error with http status 413
Bug: T291754
Change-Id: I5906fb6b4412b161b198df0b51e2476e7e1079b8
Implicitly marking parameter $... as nullable is deprecated in php8.4,
the explicit nullable type must be used instead
Created with autofix from Ide15839e98a6229c22584d1c1c88c690982e1d7a
Break one long line in SpecialPage.php
Bug: T376276
Change-Id: I807257b2ba1ab2744ab74d9572c9c3d3ac2a968e
Use
$request->getRawVal( 'key' ) ?? 'default'
instead of
$request->getRawVal( 'key', 'default' )
The ?? is more flexible, avoids a wrong type detection by phan and
avoids the evaluation of the default value if not needed.
Bug: T376245
Depends-On: I3ed6b85c0d117ed7cb3a8b79f73a3eb42977891e
Change-Id: I8b02f9297b76d04e21f8cb9194f3b85631956eca
Move deduplication of language links out of Parser.php and into the
ParserOutput in order to be compatible with alternate Parsers (Parsoid).
Clean up various inconsistencies: ensure deduplication also happens in
OutputPage when multiple ParserOutputs are merged into the final output,
and ensure that the deduplication in LinksUpdate is done in the same
order (first link prevails) as in Parser/ParserOutput/OutputPage.
Deprecate OutputPage::setLanguageLinks() (the matching
ParserOutput::setLanguageLinks() was deprecated in 1.42).
As a breaking change, return an array, not an array *reference*, from
ParserOutput::getLanguageLinks(). This allows us to safely modify the
internal representation of language links. As far as I can tell, no one
used the returned reference to sneakily modify the list of language
links, and there not a good way to have deprecated this before making
the breaking change.
While we're at it, we've added tests to ensure that language link
fragments are preserved.
Bug: T26502
Bug: T358950
Bug: T375005
Change-Id: I82a05a51d94782ebb9fa87ff889ca0f633b3e15c
This avoids addition of new code with the deprecated global,
or at least it gives extra attention on review when new code also uses
the inline ignore
Change-Id: I5c1bc5a1685c28f153d4fbe3525959930f54b557
Providing the function name is often optional from the php code,
but it is needed for better logging, so make it mandatory and let phan
report issues about this.
Bug: T374546
Depends-On: Iaed5489a85a5a6e685829e151436afc94310fbd0
Depends-On: Ie2a1e5052e5b61bbb5b89905de942f47d3f1413d
Change-Id: I5227f2fa65850ac8c6f620900f22d1f4e7bfd470
Callers should not catch an unchecked exception, so it doesn't belong
in a function signature. Unchecked exceptions indicate a coding error,
which by definition the code will not be able to handle correctly.
If any of these exceptions were supposed to be in response to an edge
case, user input, or initial conditions, then they should be changed
to a runtime error. If the exception class cannot be changed, then
the annotation should include a comment explaining its purpose and
prognosis.
Bug: T240672
Change-Id: I2e640b9737cb68090a8e1cb70067d1b74037d647
