Bug report
phpstan/phpstan-src#3302 has implemented narrowing based on the count of items in an array. But this relies on treating the shaped as sealed while analyzing valid method arguments treats all values as unsealed. This makes the static analysis mismatch with the runtime behavior of the code, making issues go undetected.
Code snippet that reproduces the problem
https://phpstan.org/r/6152adda-09b3-4920-8152-06be18efcd18
Expected output
There is 2 valid output for that:
- Reporting an error about accessing
short and reporting an error about passing the extra key when calling the function. This is the behavior when treating the shape as sealed
- Reporting an error when accessing
details as it might not always be defined in the union (behavior for unsealed shapes)
See https://3v4l.org/v7boM for the execution of that code snippet, showing that it fails on line 12, where phpstan currently does not report any issue (in scenario 2, an error would be reported on line 12, while scenario 1 would report it on line 16, which is the previous frame in the stack trace of the warning).
Did PHPStan help you today? Did it make you happy in any way?
No response
Bug report
phpstan/phpstan-src#3302 has implemented narrowing based on the count of items in an array. But this relies on treating the shaped as sealed while analyzing valid method arguments treats all values as unsealed. This makes the static analysis mismatch with the runtime behavior of the code, making issues go undetected.
Code snippet that reproduces the problem
https://phpstan.org/r/6152adda-09b3-4920-8152-06be18efcd18
Expected output
There is 2 valid output for that:
shortand reporting an error about passing theextrakey when calling the function. This is the behavior when treating the shape as sealeddetailsas it might not always be defined in the union (behavior for unsealed shapes)See https://3v4l.org/v7boM for the execution of that code snippet, showing that it fails on line 12, where phpstan currently does not report any issue (in scenario 2, an error would be reported on line 12, while scenario 1 would report it on line 16, which is the previous frame in the stack trace of the warning).
Did PHPStan help you today? Did it make you happy in any way?
No response