Avoid falsely specifying never types via count()
#3898
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thank you! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refs #3709 (comment)
The issue was that in a falsey scope with
count(array{stdClass}) < int<1, max>it wasn't able to further narrow down the array, and return it assureNotType, leading to*NEVER*in the end. Hope I'm not inversing the logic too much here.. Then it would try to use never with an array operation, leading to*ERROR*which basically made it then behave like mixed afterwards.I hate the complex if conditions. This could be somehow more simplified I think, but there are some special cases in the
list-count.phptest which deals basically with removing arrays from a union of arrays by narrowing via count in both truthy and falsey scopes and I ended up with at least 2 of those not working properly anymore. So this, apparently better, exclusion strategy it is..Unfortunately "unfixes" phpstan/phpstan#1311, but https://phpstan.org/r/a1ce8144-60c8-43fc-bfac-fcb7086b3a25 shows it was never really properly fixed anyway.