Implement TypeSpecifierContext->getReturnType()

[staabm]

trying a minimal approach to see whether the idea works as a whole

---

for expression like

if (doFoo() > 0)

we want to pass the context specific return-type information into type-specifying extensions so they can decide not just on true/truethy/false/falsy but also on "remaining return type values" (e.g. preg_match returns 0|1|false)

this should help to reduce the number of hardcoded hacks within the TypeSpecifier und move over some cases into extensions (which also allows 3rd party extensions todo similar things, as they can't hard-code hack the TypeSpecifier)

ondrej quoted:

There should be a new method on the context, can be getReturnType

Let’s say we have doFoo(): int
if (doFoo() > 0), in the then branch, this should return int<1, max>, in the else branch it should return int<min, 0>

[staabm]

drop the caching, as context now contains an additional Type (state)

on my machine this did not make a difference in performance

[staabm]

atm I whitelisted the cases which I dropped above to keep my sanity.
I feel we can drop it after we removed the hard-coded case list and moved the logic into extensions

[staabm]

the case failling in webmozart-assert is effectively

<?php

declare(strict_types=1);

class HelloWorld
{
	public function sayHello($m): void
	{
		\PHPStan\dumpType(
			is_string($m)
			&& strlen($m) >= 1
			&& strlen($m) <= 0
		);
	}
}

not sure what todo with it atm.

edit: fixed with 19749e8

[staabm]

debugging some more, I think more precisely the problem is here:

<?php

function sayHello(string $m): void
{
	if (strlen($m) >= 1) {
		if (strlen($m) <= 0) {
			\PHPStan\dumpType(
				$m
			);
		}
	}
}

it dumps non-empty-string instead of *NEVER*

edit: fixed with 19749e8

[staabm]

we might move this into TypeSpecifier instead.

when $callType instanceof NeverType turn all non-by-ref-args into *NEVER*.
not sure its required though.

[phpstan-bot]

This pull request has been marked as ready for review.

[staabm]

//cc @herndlm

[staabm]

In the future we could use this new api also for == and === not just < I think.