Support dynamic name expressions in rules

[zonuexe]

resolve #3885 (review)

[ondrejmirtes]

This applies to all the rules. We need to pair each name with its own Scope.

Let's say we have this code:

if (rand(0, 1)) {
    $foo = 'doFoo';
    $bar = 1;
} else {
    $foo = 'doBar';
    $bar = 'a';
}

$this->$foo($bar);

If the first parameter of doFoo accepts int, and the first parameter of doBar accepts string, this code should not report any errors.

You can see the way it should be done here:

phpstan-src/src/Analyser/MutatingScope.php

Line 2149 in ef6cc0a

->filterByTruthyValue(new BinaryOp\Identical($node->name, new String_($constantString->getValue())))

Also please feel free to do the same thing here:

phpstan-src/src/Rules/Properties/AccessPropertiesCheck.php

Line 47 in ef6cc0a

$names = array_map(static fn (ConstantStringType $type): string => $type->getValue(), $scope->getType($node->name)->getConstantStrings());

(I thought it already works but apparently not).

[staabm]

ohh wow. thats clever.

[ondrejmirtes]

Please write less clever code without multiple array_map and array_column calls. A simple foreach would suffice!

[ondrejmirtes]

Nice! Now please do it consistently for all the touched rules. Thanks.

[phpstan-bot]

This pull request has been marked as ready for review.

[ondrejmirtes]

Perfect, thank you! Please add the new error in a single rule and once we agree how it should work, you can copy the approach to other rules.

[VincentLanglet]

I think it solved phpstan/phpstan#2920

Should I write a non regression test or someone already on it ?

And seems like it also solved phpstan/phpstan#7990

For the issue phpstan/phpstan#4608, I'm not sure... Seems like there is a regression since
the last two lines of

$c = new class {
	public function abc(): void {}
};

$s = rand(0, 1) ? 'abc' : 'not_abc';

$c->{$s}();
call_user_func([$c, $s]);
[$c, $s]();

are not reported anymore. @ondrejmirtes @zonuexe

[ondrejmirtes]

phpstan/phpstan#2920 does not need a regression test, there are many examples of tests in this PR with the same value here already. Same for phpstan/phpstan#7990.

In phpstan/phpstan#4608 the lines 10 and 11 stopped being reported in september 2022, unrelated to this PR.