This pull request has been marked as ready for review.

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?

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)

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

This pull request has been marked as ready for review.

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

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

We just need to fix the failing tests 😂

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

Fix the bugs

ready for another review. added loads of new tests

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 😊

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 ..?

thanks for the hints.

I have added support for Stringable objects and callable types.
callables are interessting because they can be coerced to array/string in weak and strict mode
https://3v4l.org/WJ8NW

intentionally I did not add array types, as I don't find a example in which they can be coerced.
I have added tests for the cases I could think of, but these did not need adjustments in one of the toCoercedArgumentType Type methods.

I have also added tests for void type and these also did not need adjustments in toCoercedArgumentType Type methods.

@staabm These coercions are described on PHP website. See the links near the bottom at https://www.php.net/manual/en/language.types.type-juggling.php

Converting to boolean
Converting to integer
Converting to float
Converting to string
Converting to array
Converting to object
Converting to resource
Converting to NULL

I'm especially worried about those array accessory types because they just return this, I'm not sure what would happen for example when you have non-empty-array and try to assign it into integer, whethey it'd work properly or not.

I think the conversion rules on these manual pages describe what happens on explicit casts.
property assigments doen't apply the same rules.

see e.g. https://3v4l.org/H5XnR while you can cast a 1 to array, you cannot assign 1 to a array typed property

for example when you have non-empty-array and try to assign it into integer, whethey it'd work properly or not.

just added tests for the mentioned cases

As I understand it, implicit conversion only happens for the listed scalar types

Oh interesting, didn't know about that.

Alright, I'm really excited about this, let's try it out!

Hi @staabm,

I just saw this and I have some question about this change.

1. Why https://phpstan.org/r/908e9206-cf9a-4148-8e3b-18805be3ab1a is still reported in strict-types 0 but
   https://phpstan.org/r/5075f3d0-f6c6-42ed-bf20-7292529cd705 is not reported anymore in strict-types 0 (but still in strict-types 1).

2. When I have an existing codebase I want to migrate from strict_types 0 to 1, I generally rely on PHPStan to prevent futur error. If I understand this PR, it's now not possible now since some error are not reported anymore. What about an option to tell PHPStan to keep consider files like strict_types=1 even if they currently are strict_types=0 (and this option could be activated in strict-rules) ?

Huhu

The PR is about type inference, meaning PHPStan better know when/which types flow thru the code. It does not change the rules when errors are reported.
(Which type accepts which)

Regarding BcMath\Number. it behaves like that because the php runtime only errors when strict_types=1, but for strict_types=0 it's legale to assign a object which implements __toString to a string.

I don't know whether this makes sense. In case you want strict_types=1 you can declare it and work on the errors. ondrey might have a clear opinion on it

The 2 different modes have different characteristics and not necessarily everyone want to migrate from weak to strict.

I have recently seen discussions of php-src devs whether a new mode should be implemented which is a mix of the 2 existing ones, as both have some advantages

@VincentLanglet This behaviour didn't change with this PR. If PHPStan reports errors in the same situations where PHP reports TypeError, it's correct.