@no-named-arguments leads to static analysis errors for variadic arguments

[m-vo]

Q	A
PHPUnit version	at least version 9

Summary

The InvocationMocker class is annotated with @no-named-arguments - as this is on a class-level, it also affects the with() function, that only has a single variadic argument. This leads to static analysis issues.

Current behavior

When using PHPStan in a project where with() is used with an array (not a list), this may lead to a static analysis error (although the keys are ignored anyways):

 Method […]\InvocationMocker::willReturn() invoked with unpacked array with possibly string key, but it's not allowed because of @no-named-arguments.

How to reproduce

$input = ['a' => 'foo', 'b' => 'bar'];

$mock->with(...$input); // invalid
$mock->with(...array_values($input)); // valid

$mock->willReturn(/* … */);

Expected behavior

Both cases are a valid usage, so I'd expect there would be no static analysis errors.

[sebastianbergmann]

This sounds like a shortcoming of PHPStan to me.

What do you think, @ondrejmirtes @staabm?

[m-vo]

PHPUnit could in theory make use of the array keys of a ...$parameters argument, i.e. to map it as named parameters to the mocked function. But any name changes to the PHPUnit method signature would not break the consumer's code.

But in general, you could use the $parameters to invoke a library function, and then it would matter again. So not sure if PHPStan would have a way to detect this.

[ondrejmirtes]

Not sure what PHPStan should do here. This is named arguments call:

$input = ['a' => 'foo', 'b' => 'bar'];

$mock->with(...$input); // invalid

So PHPStan marks it as such. If you think there should be some exceptions to what is marked as valid and invalid with @no-named-arguments, please open a feature request on PHPStan's GitHub.

[ondrejmirtes]

My opinion is that if PHPUnit allows this use-case, there shouldn't be class-wide @no-named-arguments, but only above methods which do not support named arguments.

[sebastianbergmann]

PHPUnit has @no-named-arguments for all classes, interfaces, traits, functions because parameter names are not covered by the backward compatibility promise for PHPUnit.

That being said, the argument can be made to have an exception from this rule. However, I am not sure that the use-case mentioned here is actually supported.

[m-vo]

However, I am not sure that the use-case mentioned here is actually supported

What do you mean? Why shouldn't it be OK to pass an associative array to a function that just decides to use its values? There is nothing bad in doing so.

[sebastianbergmann]

What does passing an associative array as an argument have to do with named arguments?

[staabm]

in combination with the ... operator the named keys of the argument array is mapped to the variable names
https://3v4l.org/gON2X