Closed gsteel closed 2 years ago
After this change we got a lot of PHPStan errors.
Return type (array) of method Application\Form\Fieldset\File::getInputFilterSpecification() should be compatible with return type (*NEVER*) of method
Laminas\InputFilter\InputFilterProviderInterface::getInputFilterSpecification()
Application\Form\Fieldset\File::getInputFilterSpecification()
looks like this.
public function getInputFilterSpecification(): array
{
return [...];
}
@FabianKoestring can you please make a reproducer snippet on https://phpstan.org/try ?
Also, please do so in a new issue :)
@FabianKoestring can you please make a reproducer snippet on https://phpstan.org/try ?
I would do that but I don't know how to set dependencies (to laminas/laminas-inpufilter
) on https://phpstan.org/try. The problem occurs from version 2.16.0 on.
@FabianKoestring copy in all symbols that affect your issue, and reduce the example to the minimum size to show the issue.
@FabianKoestring copy in all symbols that affect your issue, and reduce the example to the minimum size to show the issue.
👍 Look at error on line 62. https://phpstan.org/r/91e0e318-0ada-4777-9e50-983a0d7678a1
Return type (CollectionSpecification|InputFilterSpecification) of method HelloWorld::getInputFilterSpecification() should be compatible with return type (NEVER) of method InputFilterProviderInterface::getInputFilterSpecification()
Simplifying your example further, it looks like phpstan doesn't understand this syntax:
array{
type?: class-string<InputFilterInterface>|string,
}&array<array-key, InputSpecification>
See https://phpstan.org/r/6e758234-f4ef-4ff6-8519-919f3c9297e4
I would report an issue in upstream phpstan/phpstan-src
@gsteel Please check https://github.com/phpstan/phpstan/issues/7475#issuecomment-1155259861
The problem with the InputFilterSpecification
type is that is seems valid to me. From what I can tell, the factory accepts [?'type' => 'FQCN or alias']
and also the array will contain a list of either Inputs or InputFilters or specification arrays. The keys of the list can be strings or integers - string keys are used as the input name (This is the assumed behaviour) and integer keys are replaced with the 'name' from the input spec (value).
At the expense of allowing integer keys, the type could be array{type?: whatever}&array<string, InputSpec|InstanceType>
It currently seems to me that the intersection type is the right thing but I'd gladly learn of a better/more precise way to represent this…
Description
If https://github.com/laminas/laminas-servicemanager/pull/137 gets merged, this is what I had in mind for
inputfilter
,filter
,validator
andview
… and others??