Changes to the use statements done automatically via script
Addition of missing use statements done manually
Change-Id: I8e049e495a0d0f3a0e1ee02a8252354b12604bf9
This is not really anything new. Most code already followed these
sniffs. This patch just fixes the remaining exceptions. Also:
* Remove PHPDoc blocks that don't add anything but just repeat the
strict types.
* Remove @file comments in favor of class-level comments.
* Add strict types where possible, most notably some `void`.
Change-Id: Iff6872dff68170b0fc4e82ac2ba3cad385e8773e
So far we show nothing but the index in the "paramOrder" array. This
is especially useless when a parameter is missing. The index just
points to the end of the array then.
Same when an unknown parameter appears. What the user needs is not
the index but the name of the unknown parameter.
I played around with a few formats. As suggested in this patch:
Required property "paramOrder[ "foo" ]" not found.
Invalid value for property "paramOrder[ "foo" ]".
A possible alternative is:
Required property "paramOrder[0] ("foo")" not found.
Invalid value for property "paramOrder[0] ("foo")".
Bug: T340377
Change-Id: I1dbef1b6e585d5b972a0c9a373a040aee6027cf3
Note this will make the templatedata API temporarily fail for
templates that are affected by this, until their documentation is
fixed. I think we have two ways to proceed here:
1. Thanks to Ie572809 we can change the API module to not do the
validation again. This allows us to make the validation more strict,
but the API module will continue to deliver the same data as before
until the parser cache is invalidated.
2. We accept it and merge this patch as it is. The problem is
extremely rare and easy to fix.
Bug: T333826
Change-Id: I16c7cc2328c47dde196e2dc07edb2eace33a624f
This makes it possible to use these steps independent from each
other. For example, a future patch can get rid of the re-validation
that's done over and over again when the API is called.
A significant change is that this gets rid of an expensive deep
clone. It was necessary before exactly because validation and
normalization was intertwined. Normalized properties would mess with
the later inheritance.
Strictly splitting validation and normalization (and executing them
in this order) solved this. The only downside of this is that
inherited properties are validated twice. But this is much less of a
problem, compared to the deep clone, I would like to argue.
This was always covered by tests. You can still see the tests fail
when you flip the execution order of inheritance and parameter
validation.
Bug: T301337
Change-Id: Ie5728094f9ed813f53b709d8b5283c4b99dc7d63
This only moves code around but doesn't change anything. The tests
should prove this. The only change is that validating if "inherits"
points to an existing parameter is now done a little earlier as part
of validateParameters().
Bug: T301337
Change-Id: I20865d8f93ea0f3cb1c0683804c7871056a700a8
I tried to write a test that can cover this code, but realized it is
unreachable. All parameters with all their properties are already
validated in the first loop.
Bug: T301337
Change-Id: If97adba45beb0ef1303907746715613fca23468e
PHP is a little weird in so far that what you get from e.g. `(object)[]`
or json_decode() are not objects but stdClass instances. You can think
of stdClass as a subclass of object, i.e. it's more specific.
Using is_object() means that stuff like ArrayIterator will be accepted,
which is not correct in this context here.
Change-Id: I0bffc54508ac7a27bbb59c3aabb9695158eb96b3
The word "param" is not really that ambiguous in this context. The
only other meaning it could have is "parameter name". Such places
already use $paramName.
This makes the following patches easier to review.
Change-Id: I1e6210d1ca7d58726a0fc3b3396d75e0e28c16d8
No functional change was made to the code. It was only moved from one
place to another. Note there are a lot of tests that cover this code.
The tests haven't been touched on purpose. Splitting these as well
is something for a later patch.
Bug: T260980
Change-Id: I9fa0fa87768f2560b83a1b5f3d39211ea9d6cfad
