implemented str_contains FunctionTypeSpecifyingExtension

[staabm]

first str-family-function to infer non-empty-string type.

Initially had the idea of putting everything into a single StrFamily* extension, but then figured that the semantics between substr, substring, strpos, stripos, str_contains etc are too different, and it would be more readable to put each of them into a separate extension.

therefore this is the first PR. if merged, I will work on similar semantics for the remaining functions

refs phpstan/phpstan#6792

[ondrejmirtes]

It's not ideal but this feature has to wait because it can lead to these kinds of errors:

Call to function str_starts_with() with non-empty-string and 'I' will always evaluate to true.

[staabm]

What do you think about enabling it via bleedingEdge?

alternatively could type-validation be prevented by passing $overwrite=true to the type specifier

didn't work... not sure why yet

[staabm]

did some debugging and found out, that the $override flag in this case atm does not work as I initially thought, because the override flags value is lost when SpecifiedTypes->unionWith(...) is invoked.

phpstan-src/src/Analyser/SpecifiedTypes.php

Line 86 in e52e32e

return new self($sureTypeUnion, $sureNotTypeUnion);

just added a test and a fix for that

[staabm]

optimal would be a non-empty-string here.. but the extension as-is cannot deliver it atm.

I have no idea yet, how a type-specifying extension could evaluate a comparision like if (strstr($s, ':', true) === 'hallo') {.
atm I am only verifying a plain string type, to make sure the new extension does not scramble the existing type in this scenario

[staabm]

Comparison based inference can be implemented like df27a12 but === should be preferred over ==

[staabm]

the PR now contains various str-containing functions, no longer a str_contains only case as the PR title suggests.
(I did not change the PR title, as I know it would lead in some extra work for ondrey)

[ondrejmirtes]

The problem here is still this: #1068 (comment)

Unfortunately $overwrite=true is not a solution, just a workarodun, and it'd lead to more bugs.

[ondrejmirtes]

Looks like my idea is going to work :) /cc @herndlm

[ondrejmirtes]

Thank you!

[staabm]

thx for getting this over the finishing line <3.

could you elaborate a bit, what this FAUX_FUNCTION thing is about?
is this a kind-of workaround, which should be encapsulated in a helper somehow, so the code gets readable for non-phpstan-hard-core users :-)?

[herndlm]

it's kind of the soft force flag xD but I agree, it is hard to understand and workaround-ish, maybe it should end up in some kind of helper or smth like that hmm

[herndlm]

on the other hand this is veeery special and the expression is different for each case maybe

[ondrejmirtes]

The thing that's problematic for str_contains() type-specifying extensions and similar is that PHPStan thinks the function is is_string_non_empty() because it narrows down the type to non-empty-string. But there are other properties of the narrowed string than that - in this case that it contains another string which can't be expressed by the PHPStan typesystem.

So when you call str_contains($nonEmptyString) PHPStan thinks it's is_string_non_empty($nonEmptyString) and that it has to be always true. But in fact it should be is_string_non_empty($nonEmptyString) && string_contains_string(...). So that's what I'm simulating here.

I don't think we need a helper here.

[herndlm]

Looks like my idea is going to work :) /cc @herndlm

I have not quite decided yet if I really like that modified expression thing. Potentially we then have x different ways of working around that.

I also found phpstan/phpstan-webmozart-assert#134 (double executing code would not report, but that's maybe ok to live with)