More precise types after assignment when strict-types=0

[staabm]

Improve types on top of #3945 but for the non-strict-types case.

see https://phpstan.org/r/aa5d5753-eca2-4735-bebf-6479e1ab1f42

do you think we could remove nullability from the property-type in scope, as the method we call returns a native non-nullable type, even if strict-types=0...?

closes phpstan/phpstan#12946
closes phpstan/phpstan#12940
closes phpstan/phpstan#12950
closes phpstan/phpstan#12947

[phpstan-bot]

This pull request has been marked as ready for review.

[ondrejmirtes]

I don't get why this is needed and why the current logic from #3945 doesn't already work for that. Can you explain please?

[staabm]

The logic implemented in the already merged PR only takes the native type from the assignment, when one of the property-native-flattened types is a super-type of the assigment type.

In the given example the native type of the property is not a super-type of the assigment. Thats why the current logic doesn't take effect. Since we are in non-strict type-land the else-if also doesn't narrow the types.

New: as a last resort we therefore only use the native knowledge about non-nullability of the assignment, to narrow the property type in scope.

The example only works because of phpdoc types (and these types are not expressable with native types - aka param-out in this case; similar thing could happen in conditional return types)

[staabm]

scratch the previous comment.

before #3945 we always assigned a type, and since #3945 we no longer do so. we are missing a ELSE case

[phpstan-bot]

This pull request has been marked as ready for review.

[staabm]

copied the test 12393 and changed only the strict_types to 0

[ondrejmirtes]

I just forcepushed here how the code makes sense to me. We just need to fix the failing tests 😂

[staabm]

thanks for the hints.. I will look into the errors after a lunch break

[staabm]

We just need to fix the failing tests 😂

do you mean adjusting test expectations or fixing the underlying bugs?

[ondrejmirtes]

Fix the bugs

[staabm]

ready for another review. added loads of new tests

[ondrejmirtes]

I didn't mean you to start changing the toCoerced... method. It we do that, we need to do it right.

What I meant right now is to slightly adjust what the "else" branch in NodeScopeResolver does after my force-push.

It's up to you 😊

[staabm]

What I meant right now is to slightly adjust what the "else" branch in NodeScopeResolver does after my force-push.

I don't see a way how a slight change can fullfill the tests

It we do that, we need to do it right.

could you give me an idea whats "wrong" in the current PR?
do you see errors, or do you mean more precise results - like non-empty-string -> int cannot be 0 ..?

[ondrejmirtes]

This looks promising. But you haven't touched toCoercedArgumentType in some types. For example in ArrayTypeTrait, HasOffset*Type, accessory array types, NullType, ObjectType (Stringable object can be passed to string imho), ObjectTypeTrait.

For example VoidType should do (new NullType)->toCoercedArgumentType($strictTypes).