Do not remember constructor property initialization for classes with custom serialization

[phpstan-bot]

Summary

PHPStan carries the property-initialization state established by a constructor over into all the other methods of the class, so $this->prop ?? null, isset($this->prop) and empty($this->prop) get reported as redundant there. That assumption does not hold for a class that customizes serialization: unserialize() rebuilds the object without ever running the constructor, and __sleep() / __serialize() / __unserialize() decide which properties make the round trip. The reported class returned [] from __sleep(), so $this->priceInfo really is uninitialized after a wakeup, yet the ?? null guard was flagged.

Changes

• src/Analyser/MutatingScope.php
  • rememberConstructorExpressions() takes a set of property names to forget and no longer remembers PropertyInitializationExpr entries - nor the readonly PropertyFetch value entries, which are unsound for the same reason - when classHasCustomSerialization() holds.
  • New classHasCustomSerialization(): the class (or an ancestor, or a used trait) declares one of CUSTOM_SERIALIZATION_METHODS (__sleep, __serialize, __unserialize), or implements Serializable and declares unserialize().
  • New unsetInitializedProperty(), the counterpart of assignInitializedProperty().
  • rememberConstructorScope() accepts the property names to forget.

Analogous cases probed and covered by the same fix (each was reproduced as a false positive first):

• __serialize() + __unserialize(), and __unserialize() alone (PHP 7.4+ calls it even for default-serialized payloads).
• __sleep() inherited from a parent class, and __sleep() provided by a trait.
• Serializable with serialize()/unserialize().
• Promoted constructor properties.
• ??= in addition to ??, plus isset() and empty() - all three operators share PHPStan\Rules\IssetCheck.
• Anonymous classes.

Probed and deliberately left alone:

• __wakeup() on its own does not count: with default serialization every initialized property is written out and restored, so the constructor's facts still hold. Covered by an expected-error control class in the test data.
• ReadOnlyPropertyAssignRule / MissingReadOnlyPropertyAssignRule and UninitializedPropertyRule do not read the carried-over scope (they work off the constructor's own scope and the methods it calls), so they need no change.

Root cause

MutatingScope::rememberConstructorScope() keeps a whitelist of expressions whose truth survives past the constructor, and PropertyInitializationExpr was unconditionally on it. IssetabilityDescriptor turns that entry into IssetabilityLinkInfo::isInitializedThisProperty(), which IssetCheck renders as "... is not nullable nor uninitialized". Two things can invalidate the entry and neither was modelled:

1. Custom serialization - unserialize() skips the constructor, and the author's __sleep()/__serialize()/__unserialize() decides which properties come back. The fix drops the whole property part of the remembered state for such classes. The readonly-value entries in the same whitelist are unsound in exactly the same way (__unserialize() may assign a different value to a still-uninitialized readonly property), so they are dropped too.

Test

• tests/PHPStan/Rules/Variables/data/bug-15056.php - the reporter's playground sample verbatim, asserted to produce no errors in NullCoalesceRuleTest::testBug15056().
• tests/PHPStan/Rules/Variables/data/property-initialization-custom-serialization.php - __sleep, __serialize+__unserialize, __unserialize alone, inherited __sleep, trait __sleep, Serializable, promoted properties, ??= and an anonymous class, each exercised through ??, isset() and empty(); plus NoSerialization, OnlyWakeup, PromotedNoSerialization and CoalesceAssignNoSerialization control classes that must still report. Wired into NullCoalesceRuleTest, IssetRuleTest and EmptyRuleTest.
• tests/PHPStan/Analyser/nsrt/bug-15056.php - pins the inferred types: with __sleep() a readonly property assigned in the constructor is string (not 'foo') in other methods and $this->readonlyString ?? null is string|null; without __sleep() the constructor's value is still remembered.

All seven new rule-test cases were verified to fail without the source change (git stash push src/), each for the expected reason. make tests, make phpstan and make cs-fix are green.

Fixes phpstan/phpstan#15056

[staabm]

we should leave unset support out for now. concentrate this PR on the serialization use-case

[phpstan-bot]

Done — unset() support removed, PR now focused on custom serialization only.

What was removed:

• MutatingScope::unsetInitializedProperty()
• The $propertyNamesToForget parameter threaded through rememberConstructorScope() / rememberConstructorExpressions()
• NodeScopeResolver::getUnsetPropertiesInCurrentClassLike() plus the $currentClassLikeStatements / $unsetPropertiesInCurrentClassLike fields and the save/restore around nested class-likes
• The unsetInitializedProperty() call in the Unset_ branch
• tests/PHPStan/Rules/Variables/data/property-initialization-unset.php and the three testPropertyInitializationUnset() methods

What remains is the serialization fix alone: classHasCustomSerialization() (__sleep/__serialize/__unserialize, or Serializable + unserialize(), including inherited and trait-provided) gating whether PropertyInitializationExpr and readonly PropertyFetch entries survive rememberConstructorScope().

Verification:

• make tests — 21223 tests, 96744 assertions, OK (97 skipped, pre-existing)
• make phpstan — no errors
• make cs-fix — no violations
• Reverted src/Analyser/{MutatingScope,NodeScopeResolver}.php to the pre-PR state and confirmed all four remaining serialization tests fail for the right reason (Sleep, SerializeAndUnserialize, OnlyUnserialize, InheritsSleep, SleepFromTrait, OldSchoolSerializable all reported), then restored and confirmed they pass.

One thing left as-is: the base commit's message still reads "...custom serialization or unset($this->prop)". I didn't reword it, since amending would change the SHA the review comment is anchored to — the PR title is already accurate, so a squash-merge picks that up.