Include the PHP_INT_MIN float overflow in abs() and unary minus of unbounded integer types

[phpstan-bot]

Summary

abs(PHP_INT_MIN) cannot be represented as an int – it overflows to the float 9.223372036854776E+18. PHPStan already knew this for constant operands (#6028), but abs() of a non-constant int was still inferred as int<0, max>. That made WordPress core's absint()

function absint( $maybeint ): int {
	return abs( (int) $maybeint );
}

look correct even though it fatals on PHP_INT_MIN (Trac 65826).

abs() and unary minus now include the overflow float whenever the operand's type can hold PHP_INT_MIN, so the missing return-type error is reported.

Changes

• src/Type/IntegerType.php – toAbsoluteNumber() returns int<0, max>|9.223372036854776E+18.
• src/Type/IntegerRangeType.php – toAbsoluteNumber() unions the overflow float when the range can hold PHP_INT_MIN (unbounded lower bound, or min === PHP_INT_MIN), and returns the float on its own for the range that holds nothing but PHP_INT_MIN. The remaining integers can only reach PHP_INT_MAX, so the integer part of the result is unchanged.
• src/Reflection/InitializerExprTypeResolver.php – getUnaryMinusType() applies the same overflow to -$x for non-constant integer operands (the analogous case; constants were already handled). The now-unnecessary /** @var int|float */ in getUnaryMinusTypeFromType() was removed along with its phpstan-baseline.neon entry.
• src/Type/Constant/ConstantIntegerType.php – toAbsoluteNumber() now branches on is_int(abs($this->value)) instead of comparing against PHP_INT_MIN. The old comment said that form was dead code to PHPStan itself; it no longer is, which doubles as a self-check of this fix.
• tests/PHPStan/Command/ErrorFormatter/BaselineNeonErrorFormatterTest.php – documented $expectedNewlinesCount as int<0, max>, which is what the data provider supplies; -($count + 1) is otherwise correctly reported as possibly overflowing.

Analogous cases probed:

• Fixed: unary minus -$x on int, int<min, N>, negative-int, ?int and unions containing them.
• Already correct, left alone: abs()/negation of int<0, max>, positive-int, int<-5, 5> and every other range excluding PHP_INT_MIN; unary plus; FloatType, ConstantFloatType, StringType, array and object types (their toAbsoluteNumber() cannot produce the overflow); UnionType/IntersectionType, which just delegate; first-class-callable / array_map('abs', …) paths, which go through the same Type::toAbsoluteNumber().
• Deliberately not changed: $x * -1, $x + $y, $x - $y on unbounded ints. PHPStan does not model integer overflow for binary arithmetic at all, and doing so would turn every int arithmetic expression into float|int. Unary minus and abs() are different: a single input value overflows and the resulting type stays precise.

Root cause

Type::toAbsoluteNumber() and unary minus modelled negation as a total function on integers. It is not: -PHP_INT_MIN is the one input whose result does not fit in an int. The previous fix handled it only where the value was known exactly (ConstantIntegerType), and IntegerRangeType::toAbsoluteNumber() explicitly approximated the overflow away by treating abs(PHP_INT_MIN) as "unbounded int" (see the comment removed in this PR). Everything reachable through an unbounded or PHP_INT_MIN-anchored integer type therefore lost the float.

The fix pushes the overflow into the three places that can produce it – IntegerType::toAbsoluteNumber(), IntegerRangeType::toAbsoluteNumber() and InitializerExprTypeResolver::getUnaryMinusType() – and keeps them in agreement about the boundary: the overflow is included exactly when PHP_INT_MIN is a possible value, and excluded from PHP_INT_MIN + 1 upwards.

Test

• tests/PHPStan/Analyser/data/abs-64bit.php – the reported reproducer abs((int) $maybeint), plus the boundary: int<-9223372036854775808, …> includes the float while int<-9223372036854775807, …> does not, and int<min, -9223372036854775808> (which collapses to a single value) is the float alone.
• tests/PHPStan/Analyser/data/unary-minus-64bit.php – the analogous unary-minus cases: -$int, -((int) $s), int<min, 5>, the PHP_INT_MIN + 1 boundary, plus int<0, max>, int<-5, 5> and unary plus as negative controls.
• tests/PHPStan/Rules/Functions/data/bug-15069.php + ReturnTypeRuleTest::testBug15069() – the end-to-end consequence: function absint($maybeint): int { return abs((int) $maybeint); } and function negate(int $i): int { return -$i; } are now reported, while the guarded and bounded-range variants are not.
• Updated existing expectations in nsrt/abs.php, nsrt/binary.php, nsrt/integer-range-types.php, nsrt/bug-9224b.php and Fiber/data/fnsr.php, which were asserting the old approximated types.

Both new tests were verified to fail without the src/ changes.

Fixes phpstan/phpstan#15069

[zonuexe]

The Static Analysis failures point at IntegerRangeType.php:102 and 168: the (int) ceil($value) casts in createAllSmallerThan() and createAllGreaterThanOrEqualTo() now receive 9.223372036854776E+18.

That overflow float equals (float) PHP_INT_MAX, so it slips past the bound guards:

var_dump(9.223372036854776E+18 > PHP_INT_MAX); // false

$value > PHP_INT_MAX no longer returns early for it, and it reaches the (int) cast. The guards would need to treat a float at (float) PHP_INT_MAX as out of range.

[staabm]

adjust per feedback in #6207 (comment)

[phpstan-bot]

Addressed the review. One commit, pushed to create-pull-request/patch-du7o7vj (39ba96882).

What was wrong

The reviewer's diagnosis was right, and it's worse than an unreachable (int) cast — the two guards return the exact opposite of the correct answer. Confirmed against the built types:

before                                                after
createAllSmallerThan(9.223372036854776E+18)        = *NEVER*   →  int
createAllGreaterThanOrEqualTo(9.223372036854776E+18) = int     →  *NEVER*

(float) PHP_INT_MAX rounds up to 2 ** 63, so $value > PHP_INT_MAX is false for a float that equals it, the early return is skipped, and (int) ceil($value) wraps around to PHP_INT_MIN. User-visible before the fix (bin/phpstan analyse -l 8, 9223372036854775808 is a float literal since it doesn't fit an int):

if ($i < 9223372036854775808) {
    \PHPStan\dumpType($i);   // *NEVER*  — every int is smaller than 2 ** 63
} else {
    \PHPStan\dumpType($i);   // int
}

That float is precisely what abs()/unary minus of PHP_INT_MIN overflow into, which is how this PR started routing values into it.

Change

src/Type/IntegerRangeType.php — createAllSmallerThan() and createAllGreaterThanOrEqualTo() now guard with $value >= (float) PHP_INT_MAX, with a comment on why the boundary is >= and not >. The largest float below 2 ** 63 is 2 ** 63 - 1024, which is <= PHP_INT_MAX, so everything reaching (int) ceil($value) is now in range.

createAllSmallerThanOrEqualTo() and createAllGreaterThan() already used >= PHP_INT_MAX / >= PHP_INT_MAX, which handles the boundary correctly; the PHP_INT_MIN guards are exact because (float) PHP_INT_MIN is -2 ** 63 exactly. Both verified, left alone.

Test

tests/PHPStan/Analyser/data/integer-range-float-bounds-64bit.php (registered under the PHP_INT_SIZE === 8 branch of NodeScopeResolverTest): all four comparison operators against the out-of-range float, the -9223372036854775808 counterpart as a negative control, and 9223372036854774784.0 — the largest float still inside the integer range — to pin the boundary from below.

Verified it fails without the src/ change (4 inverted assertions on lines 15/17/33/35) and passes with it.

Verification

• make tests: 21253 tests, 96789 assertions, 0 failures (97 pre-existing skips).
• make phpstan: no errors.

One adjacent thing I found but did not change: NAN slips past all four guards too ((int) ceil(NAN) is 0 here), so if ($i < NAN) narrows to int<min, -1> instead of *NEVER*. It's pre-existing, unrelated to the overflow float, and only affects code that is dead at runtime — happy to fix it in a separate PR if you want it.