-
-
Notifications
You must be signed in to change notification settings - Fork 35
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
Psalm 5.4 upgrade #287
Psalm 5.4 upgrade #287
Conversation
|
08e60cc
to
5dc98cf
Compare
This PR needs to be merged once the upcoming version of PSalm is out (5.4.1). |
2f2083d
to
0bbe180
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to be careful not to make things way too restrictive -> I see lots of changes needed in the static analysis checks - these are all potential changes users would need to make in their own codebases.
If some of changes are unavoidable simply due to Psalm 5.4 then we can perhaps use a baseline and introduce them more gradually? Would be easier if we would only do it for a set of operations at a time so we can carefully think about how the change affects their usage.
* @return Collection<mixed, mixed> | ||
* @return Collection<TKey, T> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not too sure about this change -> it's not a given that the elements in the unwrapped collection will be all of the same type 🤔
Collection::fromIterable([['a'], [1], [true]])
->unwrap(); // ['a', 1, true]
unless static analysis is able to interpret the template T
as the union string|int|bool
in this case. I'm not sure but you could test this with a static analysis check
tests/static-analysis/unwrap.php
Outdated
{ | ||
} | ||
/** | ||
* @param CollectionInterface<string, string> $collection | ||
* @psalm-param CollectionInterface<int<0, 2>, 2|3|list{1}> $collection |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is not good, and it shows that the new type hints have made unwrap
too restrictive and incorrect in this case
Collection::fromIterable([[1], 2, 3])->unwrap()
// will result in Collection(1, 2, 3) aka `Collection<int, int>`, but the type hints think the resulting types are the same
// as were passed in the original collection
* @return Collection<mixed, mixed> | ||
* @return Collection<TKey, T> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same issue here as with the unwrap
7bbd7ed
to
5a9fa80
Compare
@AlexandruGG All good for you now? |
341f72b
to
e1f174e
Compare
a522160
to
f355cb3
Compare
@AlexandruGG Good for you? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I know this took lots of work!
Thanks! Indeed it was painful ! |
This PR: