Fix phpstan/phpstan#4090: Array detected as empty while it cannot

[phpstan-bot]

Summary

When the result of count($array) was stored in a variable (e.g., $count = count($a)) and then that variable was used in a comparison ($count > 1 or $count === 1), PHPStan did not narrow the array to non-empty-array. This caused false positives when using functions like current() on the array, which returns false for empty arrays.

Direct comparisons like count($a) > 1 already worked correctly.

Changes

• Added conditionalExpressionHolderMatches() method to src/Analyser/MutatingScope.php that relaxes the conditional expression matching for IntegerRangeType conditions, using isSuperTypeOf() instead of exact equality
• Modified filterBySpecifiedTypes() to use the new matching method
• Added regression test tests/PHPStan/Analyser/nsrt/bug-4090.php covering all three patterns from the issue (direct count comparison, variable-stored count, switch on count)

Root cause

When $count = count($a) is assigned, the AssignHandler creates conditional expressions linking $count back to $a:

• If $count is int<1, max> (truthy), then $a is non-empty-array
• If $count is 0 (falsey), then $a is array{}

When later $count > 1 narrows $count to int<2, max>, or $count === 1 narrows it to 1, the conditional expression matching in filterBySpecifiedTypes() required exact type equality (equals()). Since int<2, max> and 1 are not equal to int<1, max> (even though they are subtypes), the conditional expressions never matched.

The fix uses isSuperTypeOf() specifically for IntegerRangeType conditions, which correctly recognizes that int<2, max> and 1 are subtypes of int<1, max>.

Test

The regression test tests/PHPStan/Analyser/nsrt/bug-4090.php covers three functions from the original issue:

• foo(): direct count($a) in conditions (already worked)
• bar(): $count = count($a) with variable-based conditions (was broken)
• qux(): switch(count($a)) (already worked)

All assert that $a is non-empty-array<string> in branches where count is > 0.

Fixes phpstan/phpstan#4090

[VincentLanglet]

instanceof *Type checks are not recommended and this one looks wrong. This should rely on another condition ; maybe a Type:: method ?

Think about this: Why would the check isSuperTypeOf should be made for some types and not for some others ?

Or maybe does it means that the fix should be somewhere else ?

[phpstan-bot]

All done — both verification runs confirmed clean. The commit addressing VincentLanglet's review has been pushed to the PR.

[VincentLanglet]

Can't this be extended to more Types ?

You ddin't explain why it would work for some and not some others. Stop focusing on IntegerRange

[phpstan-bot]

All background tasks have finished. The work is complete — commit pushed, all tests and static analysis passing.

[VincentLanglet]

Remove the comment, and look for another strategy cause it should also works for UnionType and certainly some others Type.

Maybe only setting $conditions OR $specifiedExpressions in specific case ; but feel free to explore other ideas

[phpstan-bot]

All done. Every background task has completed successfully — tests and static analysis all green. The commit is pushed.

[VincentLanglet]

This produce a regression on the snippet

class AggregationParser
{
	/**
	 * @param array<string, mixed> $aggregation
	 */
	private function parseAggregation(array $aggregation)
	{
		$type = $aggregation['type'] ?? null;
		if (!\is_string($type) || empty($type) || is_numeric($type)) {
			return null;
		}

		if (empty($aggregation['field']) && $type !== 'filter') {
			return null;
		}

		$field = '';
		if ($type !== 'filter') {
			$field = self::buildFieldName();
		}

		assertType('non-falsy-string', $type);
	}

	private static function buildFieldName(): string
	{
		return 'field';
	}
}

[phpstan-bot]

Pushed. Here's a summary of the fix:

Problem: The isSuperTypeOf fallback in Pass 2 caused a regression where $type was incorrectly narrowed to 'filter' instead of remaining non-falsy-string. This happened because:

1. The guard if (empty($aggregation['field']) && $type !== 'filter') { return null; } created a single conditional expression: "if $aggregation is array<string, mixed> → $type is 'filter'"
2. When $aggregation was later known to be non-empty-array<string, mixed>&hasOffset('field') (a subtype of array<string, mixed>), the isSuperTypeOf fallback matched this single conditional expression
3. This incorrectly narrowed $type to 'filter'

Fix: Two changes:

1. Require totalConditionalCount >= 2: The isSuperTypeOf fallback only fires when there are at least 2 conditional expressions for the same target variable. This ensures it only matches proper partitions (like truthy/falsy from count() assignments) and not single disjunctive guard implications.
2. Don't propagate Pass 2 results into specifiedExpressions: This prevents cascading matches across while-loop iterations.

[VincentLanglet]

Can't the two foreach ($conditionalExpressions loop be merged into a single one ?

[phpstan-bot]

Done. Merged the two foreach ($conditionalExpressions loops into a single loop that collects $exactMatches and $superTypeMatches in one pass, then decides which to use afterward. Tests and static analysis all pass.

[VincentLanglet]

Remove conditionalExpressionHolderMatches method because you end up duplicating the equals call

[phpstan-bot]

Done. Removed the conditionalExpressionHolderMatches method and inlined the certainty + isSuperTypeOf check directly at the call site, since the equals() check was already performed on line 3230. Tests and static analysis all pass.