Treat Expr\UnaryMinus with scalar operand as scalar literal in isExprSafeToProjectThroughVariable and comparison type specifying

[phpstan-bot]

Summary

Fixes a crash (TypeError: Argument #1 ($exprString) must be of type string, int given) when analysing code with comparisons against negative integer literals in ternary assignments, such as $x = array_search($a, $ids) > -1 ? $index : PHP_INT_MAX.

Changes

• src/Analyser/ExprHandler/AssignHandler.php:
  • Added Expr\UnaryMinus && $expr->expr instanceof Node\Scalar to the isExprSafeToProjectThroughVariable filter, preventing negated scalar literals (which are not valid narrowing targets) from entering the conditional expressions map.
  • Added (string) casts in processSureTypesForConditionalExpressionsAfterAssign, processSureNotTypesForConditionalExpressionsAfterAssign, and the consuming foreach loop as defense-in-depth against PHP's numeric-string array-key autocasting.
• src/Analyser/TypeSpecifier.php:
  • Extended the Smaller/SmallerOrEqual comparison handling to skip creating sure types for UnaryMinus(Scalar) expressions, matching the existing Node\Scalar filter.
• phpstan-baseline.neon:
  • Added baseline entry for the 3 defensive (string) casts in AssignHandler.php (matching existing baseline for same pattern in MutatingScope.php).
• tests/PHPStan/Analyser/AnalyserIntegrationTest.php + tests/PHPStan/Analyser/data/bug-14542.php:
  • Added regression test reproducing the crash.

Root cause

In PHP Parser v5, negative integer literals like -1 are represented as Expr\UnaryMinus(Scalar\Int_(1)), not Scalar\Int_(-1). The isExprSafeToProjectThroughVariable method checked for instanceof Node\Scalar to skip scalar literals, but UnaryMinus is not a Scalar node, so -1 bypassed the filter. Its expression string "-1" is a numeric string, which PHP's array key semantics auto-cast to int(-1). When the code later iterated over the array and passed the key to addConditionalExpressions(string $exprString, ...), the integer caused a TypeError.

MutatingScope::filterBySpecifiedTypes already handled this case correctly (filtering Expr\UnaryMinus && $expr->expr instanceof Node\Scalar and casting to (string)), but the parallel code in AssignHandler did not.

Analogous cases probed:

• UnaryPlus(Scalar): Not a practical concern — PHP's is_numeric() treats "+1" as numeric, but PHP Parser doesn't commonly produce UnaryPlus for positive literals, and MutatingScope::filterBySpecifiedTypes doesn't check for it either.
• Other sure type consumers in TypeSpecifier (e.g., processBooleanSureConditionalTypes): These filter to Expr\Variable only, so numeric expression strings never reach them.
• SpecifiedTypes::intersectWith/unionWith/normalize: These propagate keys between arrays without typed consumption, so int keys don't cause TypeErrors (they're just passed through).

Test

• testBug14542 in AnalyserIntegrationTest: reproduces the original crash with array_search() result compared against -1 in a ternary assignment. Without the fix, throws TypeError; with the fix, analyses without errors.

Fixes phpstan/phpstan#14542

[ondrejmirtes]

And regenerate the baseline with make phpstan-generate-baseline and commit that

[ondrejmirtes]

Add RequiresPhp >= 8.0.0

[ondrejmirtes]

Because of the mixed type

[phpstan-bot]

Done. Both review comments are addressed:

1. Added #[RequiresPhp('>= 8.0.0')] to testBug14542 because the test data file uses the mixed type which requires PHP 8.0+.
2. Regenerated the baseline with make phpstan-generate-baseline — the AssignHandler.php entry moved to its correct alphabetical position.

Tests (11936 passing) and static analysis (no errors) both verified clean.