Background

Code responsible for processing user requirements conditions for purpose of autopromotion or restricted groups, doesn't bother about the what's the type of "condition type" in the condition expression.

Therefore, it's possible to set a thing like below, which has no sense and is likely to break assumptions at different abstraction layers in the condition processing code.

$wgAutopromote['hacker'] = [
    '&',
    new stdClass(),
    fn ( $foo ) => 'bar',
    false
];

Data types in various documentation comments assume that the condition type is either string or int value and we should be able to enforce that. MediaWiki core uses only ints, but there are at least two extensions (OATHAuth and TorBlock), which define conditions with string types. A consequence of MediaWiki not enforcing the condition types is that the hook signatures lack proper type hints for the $type parameters, example below.

/** ...
 * @param string|int $type The evaluated condition
 ... */
public function onUserRequirementsCondition(
    $type,
    array $args,
    UserIdentity $user,
    bool $isPerformingRequest,
    ?bool &$result
): void;

Type datatype of $type is not enforced to avoid runtime PHP errors on invalid data.

Idea

There should exist a new class, responsible for validating the conditions array, so that any other code can assume that the values passed are of exected types and in expected shapes. Then, we can be sure about the datatype of the condition.

What should be validated:

• Compound conditions (&, |, !, ^) don't contain empty arrays as their arguments
• The condition type is string or int