check variance of template types in properties

[jiripudil]

Picked from #2075. To sum up:

Properties are treated as invariant. The only exception is native readonly properties: I believe we can safely consider them covariant because PHPStan already makes sure that they are initialized in the constructor and only read ever since.

Similarly to methods, private properties are ignored because they do not affect subtyping in any way.

For the time being, this check also covers static properties. I still think static properties should not be allowed to reference class template types at all, but that turns out to be difficult to do the right way (#2232), so I say let's leave it unresolved for now. I doubt people are using template types in static properties anyway, because they are an immediate footgun.

[ondrejmirtes]

Please fix the build, I'll review it once PHPStan-on-PHPStan is green :)

[jiripudil]

Honestly, I'm not entirely sure if this part is correct. Could you give me an example of a property whose readable and writable types differ?

[ondrejmirtes]

Native property will always have the same read/write type.

[ondrejmirtes]

You can probably simplify this code by typehinting PhpPropertyReflection only (it's the return type of ClassReflection::getNativeProperty). And remove things that aren't possible (and thus untestable) with native properties.

[ondrejmirtes]

Please rebase - conflicts in config :)

[jiripudil]

Rebased :)

[ondrejmirtes]

Really nice, thank you!

[mvorisek]

@jiripudil This PR introduced phpstan/phpstan#9195 . Why property is unsafe to be covariant when intentionally declared so?

[jiripudil]

Properties (with the exception of readonly) can be both read from and written to, which makes them invariant. Consider this function:

/**
 * @param Magic<Fruit> $magic
 */
function doMagic(Magic $magic): void
{
}

The function could assign an Apple into the object's property, and the property would happily accept it, because the type of the property in this piece of code is just Fruit:

/**
 * @param Magic<Fruit> $magic
 */
function doMagic(Magic $magic): void
{
    $magic->property = new Apple();
}

But by making the Magic's type parameter covariant, you are saying that Magic<Orange> is a subtype of Magic<Fruit>, and therefore will be accepted by the function:

/** @var Magic<Orange> */
$magic = new Magic();

doMagic($magic);

You have just mixed apples with oranges :)

[mvorisek]

Thank you - I got a little confused with the ...but occurs in invariant position in property error - maybe the error can be reworded or phpstan doc added? If I understand this correctly, there is nothing like "invariant position in property", but simply phpstan forces the user to not use covariant template in property phpdoc as it might be easily accepted by weaker template type - https://phpstan.org/r/8dbb1732-a361-46be-b771-113f1ef11de2.