Implement Scope->getPhpVersion()

[staabm]

No description provided.

[staabm]

sending it up for review to sync our expectations. if this works for you, I can add it to all rules.

when rules take the php-version from the Scope, we also need to think how we can/want control the PhpVersion in tests, so we can test PhpVersion dependent behaviour

[ondrejmirtes]

Looking at this piece of code I realized it's time to do an idea I had for a long time. Please follow my train of thought (while I'm typing this out on a train to Prague :))

Often there's not a single PHP version, but a range of them so returning bool from a method like this isn't exactly right:

	public function supportsNullCoalesceAssign(): bool
	{
		return $this->versionId >= 70400;
	}

If we're analysing against both PHP 7.3 and 7.4+, we MIGHT support null coalesce assign.

If we're analysing only against PHP 7.3, we do NOT support null coalesce assign.

If we're analysing only against PHP 7.4+, we DO support null coalesce assign.

Sounds familiar? :) We should return TrinaryLogic instead of bool.

But I don't want the headache of BC breaks. Adding a new method about PHP version to Scope allows us to return something else than PhpVersion. A new unrelated class called something like TrinaryPhpVersion or PhpVersions. And we do not need to add all methods from PhpVersion on it. We can add them slowly as needed.

So in this PR this new class could have just producesWarningForFinalPrivateMethods(): TrinaryLogic correctly computed for all various scenarious of what PHP_VERSION_ID can be in that place.

And the rule would correctly handle yes/no/maybe along with some tests.

The constructor of this class could just accept a list of supported PHP versions like 80000, 80100, 80200.... Because all methods in PhpVersion asking about this number always ask about the minor version, ending in 00. Meaning that if PHP_VERSION_ID is 80210, the 10 at the end would have to be trimmed and exchanged for 00 to correctly answer.

Does this sound compelling to you?

[staabm]

yeah I can follow this train :).

when rules take the php-version from the Scope, we also need to think how we can/want control the PhpVersion in tests, so we can test PhpVersion dependent behaviour

this is still a open question though. how to adjust existing tests so we can force the php version?

wdyt about adding RuleTestCase->getPhpVersions() with a default impl and handle it similar to getCollectors?

[ondrejmirtes]

I don't think we need anything like that. If we want to test behaviour for a specific PHP version we will just write the condition if (PHP_VERSION_ID > ...) in the tested code.

[phpstan-bot]

This pull request has been marked as ready for review.

[ondrejmirtes]

This isn't sufficient. Let's say something is supported only between 7.2 and 7.3. If our intervals only allow < 7.1 and > 8.0, it's not okay to collapse all the intervals, it loses the information.

I know this is just theoretical but let's address this now before this becomes a problem in the future.

[staabm]

I just realized we could just use the all-problem-solving Type->isSuperTypeOf, which means the PhpVersions class effectively no longer contains real logic, which requires a separate unit-test, right?

[ondrejmirtes]

I still want a test that tests the public method for no/maybe/yes. Thanks.

[ondrejmirtes]

Please do not touch existing test, I can't read this diff. It'd be better to add a completely new file with the top-level ifs. Thanks.

[staabm]

I now tried to keep the old test as much as possible

[ondrejmirtes]

Awesome, thank you! Now we can go through a lot of occurences of PhpVersion being injected in the constructor, like in rules and dynamic return type extensions, and use Scope::getPhpVersion() there instead.

[ondrejmirtes]

Also every occurence of $this->phpVersion in MutatingScope.

This assumes we'll add the used methods to PhpVersions.

[ondrejmirtes]

We can afford to start reading min/max values from the phpVersion config.