Refactoring order creates incompatible return types

[scheb]

This test case shows how the order in which files are parsed & refactored can lead to incompatible method signatures on the return type. The rector does populateChildren, but the implementation implicity relies on the superclass being processed before its subclasses to ensure return type compatibility. This in combination with the subtype logic leads to this result.

(Note: Actually I have to say I don't really understand why this subtype logic is there, since return type variance is only supported from PHP 7.4 on. Earlier versions support type variance for the "iterable" type which is there as the test case, but I have the impression that's the one single case when PHP <7.4 supports return type variance).

I'd guess an approach similar to #1842 would be the solution. Doing it the other way round: instead of refactoring children after refactoring the node itself, the parents should be refactored before the node is refactored. This would ensure the return type decision for the parent class was made by the rector and we can make a correct decision for the node itself.

Bonus objective would be to support refactoring with return type variance when PHP7.4 is set as the language level.

I'll have a look at a potential fix as soon as I find time to have a deeper look.

[TomasVotruba]

There's been major refactoring of types from string to PHPStan value object types.
Please rebase and I'll give this priority

[scheb]

Added a new test case, which is technically the same as the inheritance_covariance.php.inc test but with different parsing order.

[TomasVotruba]

Thanks 👍

I'll look at it locally