[phpstan-bot]

Summary

With unresolvedTemplateArguments (bleeding edge), an object created with a known template argument and then given values derived from reading it back kept a too-specific type:

$count = new Box(0);
repeat(5, function () use ($count): void {
	$count->set($count->get() + 1);
});
// Box<0|1>, and "Parameter #1 $value of method Box<int>::set() expects 0|1, 1|2 given."

Now the resolution is generalized when the body widens the argument beyond its initial type, so the result is Box<int> and set() accepts any int.

Changes

• src/Analyser/Generics/TemplateArgumentSolver.php: in resolveObservation(), when the union of the initial type and the lower bounds is not covered by the initial type, generalize it with GeneralizePrecision::lessSpecific().
• Updated two expectations that pinned the literal union for an object created with a known argument and then given an unrelated value: template-argument-multiple-sites.php (Coll<1|2|3> → Coll<int>) and TemplateArgumentResolverTest::testLowerBoundsUnionWithTheInitialUnlessASendWins (1|2|'a'|null → int|string|null). The solver cannot tell whether a written value was derived from a read, so any write that widens a known initial type is generalized. This trades literal precision in those cases for soundness.
• TemplateArgumentSolver has no native mirror (the native TemplateArgumentResolver instantiates the PHP solver), so no turbo-ext change is needed. The new tests pass both with and without the turbo extension loaded.

Root cause

The observation pass reads a not-yet-resolved template argument out of the object (Box<T>::get(): T) as its initial type (0). A value derived from that read and written back (0 + 1) becomes a lower bound, and the argument resolves to 0|1. In the second pass the read returns the resolution 0|1, so the write is 1|2, which Box<0|1> rejects. The resolution has to be a fixpoint of read → derive → write, which is the same situation as a loop's variables. Once writes widen the argument past its initial type, the reads the observation saw were stale, so the resolution is generalized the way loop variables are. Writes that stay within the initial type ($box->set($box->get())) keep the precise type.

The same pattern affected every way of creating the object (new, a static generic factory Box::of(0), a generic function wrap(0)). It showed up in straight-line code, for loops, closures, arrow functions, and closures invoked several times, with int arithmetic, string concatenation, and array appends/shapes. All of these are fixed by the single change in the solver.

Probed and left unchanged: assigning to a template-typed public property ($box->value = 1) is not observed as a lower bound at all (the property write goes through collectSend()). That is a separate gap in AssignHandler, not a too-specific resolution.

Test

• tests/PHPStan/Analyser/nsrt/bug-15430.php: the reported snippet plus straight-line, for-loop, arrow-function, static-factory, generic-function, string-concat, list-append and array-shape variants, and a write-back-unchanged case that stays precise (Box<0>).
• tests/PHPStan/Rules/Methods/CallMethodsRuleTest::testBug15430() with the reported snippet: no argument.type error is reported anymore.

Fixes phpstan/phpstan#15430

🤖 Generated with Claude Code