[staabm]

No description provided.

[staabm]

//cc @SanderMuller

[VincentLanglet]

Is there a reason to only auto-fix native type ?
Is there a strategy which was already used ?

[staabm]

Is there a reason to only auto-fix native type ?

people mostly use phpdoc types when they are not 100% sure whether these hold in all cases. we want auto-fixers to only change code if we are 100% confident about consequences. we don't want suprises because actual runtime types differ from what we work with.

e.g. https://3v4l.org/5b3vO#v could have bad consequences when we handle it like a int even though at runtime its not

Is there a strategy which was already used ?

I am not exactly sure what you mean. I have been doing auto-fixing stuff in e.g. https://github.com/phpstan/phpstan-phpunit/pulls?q=sort%3Aupdated-desc+is%3Apr+state%3Aclosed+auto-fixable in the past and I did it a similar way here.

does this answer your question?

[VincentLanglet]

You can still have false-positive with native type for people not using the Array String Keys feature.
https://phpstan.org/r/952b81a1-80df-4d79-b1ce-10b2f6b56d46

[staabm]

thats a great example. I think we could harden the logic by auto-fixing string casts only for property-fetches.

do you have more examples in mind?

[VincentLanglet]

do you have more examples in mind?

No the only known reported "false positive" was the famous string key for array.

[SanderMuller]

I ran the fixer on some extra cases with native types only. The PR's own tests pass. These changed the code in a way that breaks it:

• $b = $integer-(int)-$integer; becomes $b = $integer--$integer;, which is a parse error.
• foreach ((array) $array as &$v) with array $array becomes foreach ($array as &$v). The loop then writes to $array, not to a copy. In my run the array changed from [1,2] to [0,0].
• Vincent's case: strlen((string) $k) becomes strlen($k), and with strict types that throws a TypeError for the key '1'.

These two are less clear, because the cast is already reported today:

• (int) $countable->count() loses its cast, because Countable::count() has a tentative int return type. A class that implements count() without a return type can still return '5'. PHP only shows a deprecation for that.
• (int) ($integer * PHP_INT_MAX) loses its cast, and the result is a float at runtime.

A small one: (int) /* why */ $integer becomes $integer, so the comment is lost.

If the fixer only removes casts around property fetches, for all cast types, it skips every case above except the foreach one. That one stays, because foreach ((array) $this->items as &$v) writes to the property in the same way. To fix that, the fixer could skip the cast when it is the expression of a by-ref foreach.