-
Notifications
You must be signed in to change notification settings - Fork 474
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix false positives on non-existing-offset's #3766
base: 2.1.x
Are you sure you want to change the base?
Conversation
1b0239b
to
e723d34
Compare
This pull request has been marked as ready for review. |
Thanks for fixing the issue I encountered. In the description are some specific cases mentioned which are not covered by this fix. What would be required to fix those cases? I could help. |
It seems to me that Currently, there is Would it make sense to have a
This would also be an option for many more functions, such as |
thats exactly what this PR is doing.
I think thats not possible, because a
for this |
Thanks for your answer, I appreciate the insights! Could you clarify the following for me?
Is that not enough to ask the scope for the return type ( |
its enough to calculate the return-type of the thats also the reason why my current approch doesn't work for |
98f3ba8
to
ce9e0fc
Compare
@leongersen thanks to some great playground changes by ondrej, the opt-in only rule errors now show up: |
fixes some false positives we see with
reportPossiblyNonexistentGeneralArrayOffset
.basic idea is to infer a expression type for
$array[$last]
after$last = array_key_last($array);
based on the iterable-type of a non-empty$array
.refs phpstan/phpstan#11020
this PR fixes code like
but not like (in which no intermediate variable is used)