Collapse ObjectShapeType against HasPropertyType regardless of member order

[SanderMuller]

When a parameter is typed \stdClass&object{u?:int} and its value goes through isset()/?? narrowing, PHPStan should resolve the optional key to its declared type. Since 2.2.6 it fell back to mixed instead:

abstract class AbstractJsonRepresentation
{
    /** @param \stdClass $data */
    abstract protected static function fromObjectInternal(\stdClass $data): self;
}

final class MissalYearLimits extends AbstractJsonRepresentation
{
    private ?int $until_year;

    /** @param \stdClass&object{since_year:int,until_year?:int} $data */
    protected static function fromObjectInternal(\stdClass $data): self
    {
        // 2.2.5: int|null   2.2.6+: mixed  -> "argument.type" false positive at level 10
        return new self($data->until_year ?? null);
    }
}

Root cause

isset($data->until_year) narrows $data by intersecting it with a HasPropertyType for the key, and TypeCombinator::intersect() is supposed to collapse object{until_year?:int} & hasProperty(until_year) into object{until_year:int}, so the read is int.

That collapse lived in the pairwise reduction loop, reached only after the generic supertype dedup. The parameter also carries stdClass, a dynamic-property class that reports every property as present, so hasProperty(until_year) is a supertype of it and the dedup removes the HasPropertyType as redundant against stdClass. Whether the dedup drops it first or the object shape collapses it first depends on the order of the members in the intersection.

While intersection members were still sorted in place, describing the type happened to reorder them so the object shape came first and won the race. Once that in-place mutation was removed (correctly, so a type's value no longer depends on what has been called on it) the construction order took over, stdClass came first, and its mixed dominated.

Note the bare read $data->until_year without isset/?? was already mixed before and after 2.2.6. That is a separate, pre-existing gap and not what this fixes; this change is about the isset/?? narrowing path only.

Fix

Move the object-shape / HasPropertyType collapse into its own pass before the reduction loop, so member order no longer decides the outcome. Two details keep it behaviour-preserving otherwise:

• It only fires when the shape has, or may have, the key (hasInstanceProperty(...) is not no). A sealed shape intersected with a HasPropertyType for a key it cannot have is left alone, so it still reduces to never in the loop below, as it did before.
• The pass is gated on a HasPropertyType being present in the intersection, a flag computed in the existing flatten loop, so an intersection without one pays only that flag check and never enters the extra loop.

The array analogue (ConstantArrayType & HasOffsetType) is not affected: there is no universal-offset type that reports every offset as present, so nothing absorbs the HasOffsetType before the offset is made required. Verified against real 2.2.5/2.2.6 builds.

Closes phpstan/phpstan#15047

[staabm]

doesn't object{...} already imply stdClass? can't we just drop stdClass from the intersection when building the type for the phpdoc as it is already redundant?

skip that. I missremembered