Edge case: strict(er) configuration will not accept stdClass as solution for the "property is not writable" issue on objects

[MetalArend]

(Or it will, but it introduces other errors.)

The project I'm currently working on has the following configuration:

parameters:
	level: max
	treatPhpDocTypesAsCertain: true
	checkTooWideReturnTypesInProtectedAndPublicMethods: true
	checkUninitializedProperties: true
	checkDynamicProperties: true
	rememberPossiblyImpureFunctionValues: false
	checkImplicitMixed: true
	checkBenevolentUnionTypes: true
	reportWrongPhpDocTypeInVarTag: true

So far we managed to get all new code* during the last two years working just fine. We try to keep PHPStan up to date, but last week I updated PHPStan to the latest version, and I encountered an issue in some error-free (and baseline-free) code that I cannot solve.

This is a simplified version of the code piece: https://phpstan.org/r/c39fda7a-3f12-4d71-beb3-a4c466d7cf18. If I run this simplified class locally on PHPStan Pro, it throws an error. I cannot reproduce it in the public editor, because of the configuration flags.

The first version of this code did not mention stdClass. It started failing after the upgrade with the error property is not writable, as objects are by default not considered writable. The solution mentioned in a GitHub issue on the problem is to add stdClass as an intersection type. And indeed, the error goes away, but when I run it locally with the above configuration, it throws an error on the line && property_exists($node->attrs, 'class'): Parameter #1 $object_or_class of function property_exists expects object|string, mixed given..

If you do stdClass|... as a true union type, it fails both locally and the editor with the writable error, which is to be expected.

I'm not quite sure where it is going wrong, but I'm sure that I'm out of ideas to tell PHPStan what this code does... Because the code works, that's for sure.

Has anyone any idea? It is a very edge-case with a combination of multiple things that lead to this, so I thought it might be interesting to still report it, instead of simply adding it to our baseline.

[ondrejmirtes]

You researched this very well :) Fortunately we have a way of showing this problem in the playground - using type inference debugging. See: https://phpstan.org/r/624b8daa-83f0-4ac3-9e7f-ded1a646b1ae

One problem can be fixed by improving this piece of code to also account for an intersection https://github.com/phpstan/phpstan-src/blob/68aaebf0047e937ed0772706802e5ed9289a4689/src/Type/TypeCombinator.php#L1153-L1165 (to make the property required)

The other problem is happening in MutatingScope::resolveType() when it's resolving the type for PropertyFetch. Even fetching a possibly non-existent property should lead to a specific type, not mixed.

Feel free to open a bug report for this (this is just a discussion), or look into it and send a PR :) Thanks.