[westonruter]

An offset write $object[$offset] = $value was checked against the parameters of offsetSet() taken from getOnlyVariant(), so method-level template types were never resolved. With an offsetSet() declared like this:

/**
 * @template TOffset of key-of<TArray>
 * @param TOffset $offset
 * @param TArray[TOffset] $value
 */
public function offsetSet(mixed $offset, mixed $value): void;

the accepted offset type stayed the unresolved TOffset, and the accepted value type stayed TArray[TOffset]. As a result, every write was rejected, valid ones included (offsetAssign.dimType and offsetAssign.valueType). An explicit $object->offsetSet($offset, $value) call was already accepted, since a method call resolves the templates from its arguments.

Compound assignments had the same problem on the read side. A plain read $object[$offset] is analysed as a simulated offsetGet() call, so it already resolved @return TArray[TOffset]. But ??=, +=, and .= read the current value through ObjectType::getOffsetValueType(), which also used getOnlyVariant(). For Options<array{name: string, age: int}>, $options['age'] ??= 5 was reported as "does not accept int|string", and $options['age'] += 1 was inferred as an error type.

Changes

• ObjectType::setOffsetValueType() selects the offsetSet() variant from the written offset and value types, and ObjectType::getOffsetValueType() selects the offsetGet() variant from the offset type, with ParametersAcceptorSelector::selectFromTypes(), as a method call does.
• When the method has a single variant without template or late-resolvable types (ArrayObject, most collections), that variant is used as is, without resolution. On a file of 6,000 writes and compound assignments to an ArrayObject and a plain ArrayAccess<int, int> class, resolving every access cost about 15% more user CPU time. With this fast path, the difference is about 2% without the turbo extension and about 1% with it, which is within the noise of that measurement (6 interleaved runs each).
• OffsetAccessValueAssignmentRule checks the value against the written offset (null for an append) instead of mixed, so TArray[TOffset], or a conditional type such as ($offset is null ? int : string), resolves for that key. When the offset itself is rejected, the rule falls back to mixed, since OffsetAccessAssignmentRule already reports that offset. An accepted write costs one setOffsetValueType() call.
• The native ObjectType in turbo-ext gets the same changes. turbo-ext/tests/type-family.php gains observations on a templated ArrayAccess fixture, an offset-conditional one, and a generic ArrayObject. Against a build of the native ObjectType without these changes, 96 of them differ from the PHP twin. turbo-ext/src/generated/ObjectType.h is regenerated for the new private method.

Left unchanged:

• ObjectType::hasOffsetValueType() still reads offsetSet() through getOnlyVariant(). For ArrayAccess, it answers only no or maybe, and the bound of the unresolved TOffset (key-of<TArray>) already gives the right "no". Resolving the template gave identical results for unset, isset, ??, compound assignments, and union keys.
• AssignHandler::collectOffsetSetUsage() also still uses getOnlyVariant(). With unresolvedTemplateArguments enabled, an array-access write already infers the same template arguments as the equivalent explicit offsetSet() call.

Known limitation and a possible follow-up

setOffsetValueType() returns a single ErrorType whether the offset or the value is rejected. So OffsetAccessValueAssignmentRule tells the two apart by probing: it checks the write, then the offset alone, and then the value against a mixed offset when the offset itself is rejected. As a result, when an offset is only partly accepted, a wrong value for its accepted part is not reported separately. For example, with Options<array{name: string, age: int}> and 'age'|'nope' $key, $options[$key] = 'foo' gets only Cannot assign offset 'age'|'nope' … from OffsetAccessAssignmentRule, not also a value error for 'age'. The line is still reported once. Before this change, it got both errors, as did every valid write.

A way to remove the probing would be for ObjectType to expose the accepted offset and value types of the resolved offsetSet() variant. The rule could then check the value against the value type for the accepted part of the offset, with no mixed fallback, and a rejected write would cost one variant resolution instead of up to three. That would add API to ObjectType (and its native twin), so it is left out of this PR. It could be added if wanted.

Tests

The regression fixture starts with the issue's playground snippet verbatim. Further cases follow it: an unknown key, an append, a wrong value for a second key, an array<string, mixed> map, compound assignments, and union keys. tests/PHPStan/Analyser/nsrt/bug-8549.php covers the inferred types of reads and compound assignments. Each new test fails without its source change and passes with it. The full test suite passes with and without the turbo extension loaded, as does turbo-ext/tests/smoke.php. make lint-turbo and make sanitize-turbo were not run locally.

Where this came up

This was found in Gutenberg, through WordPress/gutenberg#86110. In the php-stubs/wordpress-stubs package, WP_REST_Request is declared @template T of array = array<string, mixed>, and its offsetSet() and set_param() both use the TOffset of key-of<T> / T[TOffset] pattern above. Gutenberg's attachments controller builds a request with array access:

$response_request = new WP_REST_Request( WP_REST_Server::READABLE, rest_get_route_for_post( $attachment_id ) );
$response_request['context'] = 'edit';
if ( isset( $request['_fields'] ) ) {
	$response_request['_fields'] = $request['_fields'];
}

PHPStan reported both writes, although T is array<string, mixed> and both are valid:

Cannot assign offset 'context' to WP_REST_Request<array<string, mixed>>.  (offsetAssign.dimType)
WP_REST_Request<array<string, mixed>> does not accept string.             (offsetAssign.valueType)
Cannot assign offset '_fields' to WP_REST_Request<array<string, mixed>>.  (offsetAssign.dimType)

The errors had been suppressed in Gutenberg's PHPStan baseline. That PR removes the baseline entries by rewriting the writes as $response_request->set_param( 'context', 'edit' ) and $response_request->set_param( '_fields', $request['_fields'] ). The workaround passes because set_param() is analysed as a method call, which resolves TOffset from its argument. Only the array-access path skipped that step. Array access on WP_REST_Request is idiomatic across WordPress core and plugins, though, so rewriting call sites to avoid a false positive is not a general fix.

With this change, the original array-access code passes as it is, so the baseline entries can be dropped without the rewrite. Array-access writes also get the same per-key checking a set_param() call gets. With WP_REST_Request<array{context: 'view'|'edit'|'embed', _fields?: string}>, $request['context'] = 'edit' is accepted, while $request['context'] = 'nonsense', $request['_fields'] = 1, and $request['nope'] = 'x' are reported. Before this change, all of these writes were reported, valid and invalid alike, so the errors carried no signal.

Closes phpstan/phpstan#8549

🤖 Generated with Claude Code using Claude Opus 5.5 · high effort