FP: string++ | "Only numeric types are allowed in post-increment, string given."
voku opened this issue · 5 comments
Bug report
I am uncertain if this is a "normal" use-case, but I see sometimes code like this: $a = 'a'; $a++;
... especially in some excel related code, this is working as expected.
Code snippet that reproduces the problem
https://phpstan.org/r/379c2ebf-cde5-4d10-aab2-17c9080a984a
Expected output
no error for ConstantStringType [a-zA-Z]{0,1}
Did PHPStan help you today? Did it make you happy in any way?
Currently, I am trying to enable the strict rules for a legacy project, and it's cool that we can enable one rules after another. Thanks for these features. 🥇
https://3v4l.org/FGt21
https://3v4l.org/QHiFj
Just for additional information, $a = 'a'; $a++; doesn't always mean $a === 'b' and behaves different in some encodings.
I don't have a opinion whether it is "normal" or not, but it is a documented behavior (and at least valid) https://www.php.net/manual/en/language.operators.increment.php
ConstantStringType [a-zA-Z]{0,1}
I think it should be [a-zA-Z0-9]* looking at the documentation.
I agree string++ should not be reported. But (int|string)++ still should be.
'a9'++ is computed to 'b0' which is a string
but '9' is computed to '10` which is an int.
Currently it's always considered to be a string
https://phpstan.org/r/62872dfa-096d-4b43-ad3b-6d7a8610f1ee
Should we first modify this behavior @ondrejmirtes ?
The issue is that if we change the result to int|string or (int|string), then doing
$string++;
$string++;
We will report the second line as an error since you said
I agree string++ should not be reported. But (int|string)++ still should be.
I opened a PR to at least avoid the false positive #200
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.