You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have long ago adopted a code style that enforces an explicit === false instead of a ! negation within if conditions. I noticed that this sometimes leads to false positives when using an isset() check for a key within an array, while Psalm does not find issues on the equivalent version with a ! instead of === false.
One that I've been able to reproduce in isolation:
I also see some RedundantPropertyInitializationCheck issues on if (isset($this->array[$key]) === false) patterns on our code base (like Psalm does not understand that we're checking if a specific element is set rather than if the whole array is initialized), which disappear when I switch === false to !. I haven't been able to reproduce these in an isolated case though, and hope these maybe also disappear if the above false positive is solved.
The text was updated successfully, but these errors were encountered:
Psalm output (using commit a9775c6):
INFO: MixedArrayAccess - 21:16 - Cannot access array value on mixed variable $this->foos
INFO: MixedReturnStatement - 21:16 - Could not infer a return type
INFO: MixedInferredReturnType - 17:50 - Could not verify return type 'Foo' for FooCollection::getFoo
We have long ago adopted a code style that enforces an explicit
=== false
instead of a!
negation withinif
conditions. I noticed that this sometimes leads to false positives when using anisset()
check for a key within an array, while Psalm does not find issues on the equivalent version with a!
instead of=== false
.One that I've been able to reproduce in isolation:
isset(...) === false
, gives issues)!isset(...)
, no issues)I also see some
RedundantPropertyInitializationCheck
issues onif (isset($this->array[$key]) === false)
patterns on our code base (like Psalm does not understand that we're checking if a specific element is set rather than if the whole array is initialized), which disappear when I switch=== false
to!
. I haven't been able to reproduce these in an isolated case though, and hope these maybe also disappear if the above false positive is solved.The text was updated successfully, but these errors were encountered: