fix(codegen): PHP semantics for division, modulo, shifts and compound assignment on typed scalars

[AlessioGiacobbe]

Typed int/float division fell through to a raw C++ /: divInts(7, 2) with int parameters returned 3.0 instead of 3.5, / 0 was undefined behavior instead of a catchable DivisionByZeroError, and float / 0.0 produced INF. Both-int % kept the raw C++ operator (the existing guard only routed the mixed case through php::fn::mod), and dynamic <</>> were UB for counts ≥ 64 or negative. The same divergences applied to compound assignment and ++/-- on typed local slots (7 /= 2 gave 3, += overflow wrapped).

This routes dynamic division/modulo/shifts on typed scalars through the encapsulated php::Var operators — exactly the pattern the existing + - * routing already uses, and per its comment, only outside use native_types — and lowers compound assignment/incdec on typed local slots to the equivalent plain assignment. Literal / 0 and % 0 now warn and produce the catchable runtime error like the equivalent 1 % (1 - 1) spelling already did, instead of refusing to compile guarded/dead code. Constant folds are untouched; typed-property compound assignment is handled by af466b0 and untouched here.

type_hits/native-type.phpt asserted the truncating division this removes (std::int(10) / 4 === int(2)); its expectation becomes float(2.5), consistent with the + - * contract. Verified against Zend 8.4.13; new phpt tests carry Zend-validated expectations.

Part of the split of #39.

Scope note: binary shifts with typed float operands still generate invalid C++ (double << double) — a pre-existing gap that this PR does not cover; it belongs to the follow-up typed compound-assignment work together with float %=/<<=.

[matyhtf]

Thank you for splitting this work out of #39. The general direction is correct: non-native_types division, modulo, and shifts must not fall through to C++ operations with different semantics or undefined behavior, and a literal zero divisor should remain a catchable runtime error rather than reject dead code at compile time.

However, the compound-assignment and increment/decrement part is not safe to merge yet. It computes through Variant, but then parseAssign() coerces the result back into the existing native php::Int/php::Float slot. A PHP parameter type constrains the value at function entry; it does not prevent that local variable from changing type later.

For example:

function divParam(int $value): mixed
{
    $value /= 2;
    return $value;
}

function incParam(int $value): mixed
{
    $value++;
    return $value;
}

With this PR, divParam(7) returns int(3) instead of float(3.5), and incParam(PHP_INT_MAX) returns PHP_INT_MIN instead of promoting to float. The same problem affects overflowing +=, -=, and *=.

Float compound operations expose two more cases:

function modFloat(float $value): mixed
{
    $value %= 2;
    return $value;
}

function shiftFloat(float $value): mixed
{
    $value <<= 1;
    return $value;
}

PHP produces an int result for these operations. This PR coerces %= back to float, while the shift currently generates invalid C++ similar to double << double and fails during native compilation.

The existing divEven(8) test hides the division issue by using an evenly divisible value and converting the result to string. Please add runtime coverage for:

• int parameter 7 /= 2, returning mixed;
• PHP_INT_MAX += 1 and PHP_INT_MAX++ on parameters;
• float %= returning an integer value;
• float <<=/>>= compiling and returning PHP-compatible integer values.

Suggested revision:

1. Keep the ordinary binary division/modulo/shift and literal-zero fixes.
2. Remove the typed-local compound assignment and ++/-- lowering from this PR for now, or first make analysis represent every potentially type-changing local as php::Var instead of coercing the result back into a native slot.
3. Rebase on the latest master before revising the integer-division path, because that area has recently gained an inline PHPX integral-RHS fast path and should not restore unnecessary RHS boxing.

I verified the PR's own targeted PHPUnit and PHPT tests successfully, but the cases above reliably reproduce incorrect output or a C++ compilation failure. Please update the implementation and tests before this is merged.

[AlessioGiacobbe]

Revised as suggested:

1. The compound-assignment and ++/-- lowering is removed from this PR. You're right that coercing the Variant result back into the native slot is wrong — a parameter type constrains the value at entry, not the local's later type — and the float <<= case didn't even produce valid C++. That part will come back as its own PR once the analysis can represent potentially type-changing locals as php::Var slots instead of coercing back; your four runtime cases (int 7 /= 2 via mixed return, PHP_INT_MAX += 1/++, float %= producing int, float shifts) will be its acceptance tests.
2. What remains is exactly the binary division/modulo/shift routing and the literal-zero-divisor change, rebased onto the latest master (no conflicts in the division area; the existing materialization/native fast paths are untouched — the Var routing only fires in non-native mode on the raw-operator fall-through, same as the pre-existing + - * path).

Re-verified on the rebased branch: targeted PHPUnit suites and the operator/type_hits/loop/object_property phpt front-end sweep are green, and divInts(int,int) emits ((php::Var(a)) / (php::Var(b))).

[matyhtf]

Thank you for revising the PR. The unsafe compound-assignment and increment/decrement lowering from the previous version has been removed as requested, so the earlier type-changing-local issues are no longer introduced by this branch. The remaining binary division/modulo/shift direction is sound, and the PR's targeted tests pass.

There is still one blocking regression caused by changing every literal-zero compound assignment from a compile-time fatal error to a warning.

A typed native slot continues to use the raw C++ compound operator:

function divInt(int $value): mixed
{
    try {
        $value /= 0;
    } catch (DivisionByZeroError $e) {
        return $e->getMessage();
    }
    return $value;
}

The generated code is:

value /= php::toInt(0L);

This does not enter the PHPX Variant error path. In an end-to-end PHPT it terminates the process with:

Floating point exception (core dumped)

The same issue affects:

• int $value; $value %= 0, which is raw C++ modulo by zero;
• float $value; $value /= 0.0, which produces INF instead of throwing;
• native typed locals created through paths such as std::int().

The new PHPT only tests $v = 10; $v /= 0, where $v is a php::Var, so it does not cover this path.

Please ensure literal-zero /= and %= on native scalar slots also raise a catchable DivisionByZeroError without modifying the left-hand side. A focused lowering through a temporary php::Var is possible because a proven zero divisor always throws before assignment. If that cannot be implemented safely in this PR, keep the existing compile-time rejection for native scalar slots until the separate typed compound-assignment work is ready.

Please add runtime coverage for typed int division/modulo assignment, typed float division assignment, and an explicit std::int() local.

Separately, binary shifts with typed float operands still generate invalid C++ such as double << double. That is a pre-existing gap rather than a regression from this revision, so it may be handled in the later typed-operator PR, but the current title/description should avoid implying that every typed scalar shift is covered.

[AlessioGiacobbe]

Fixed. A literal zero divisor in /=/%= on a native scalar slot (typed int/float parameters and locals, std::int() values) now lowers to the PHP-semantics binary operation through php::Var — a proven zero divisor always throws before any assignment, so the target is left untouched and the process no longer dies with SIGFPE (float /= 0.0 likewise throws instead of producing INF). Native-types mode keeps the compile-time rejection, exactly as you suggested.

Added the runtime PHPT you asked for: typed int /= and %=, typed float /=, and an explicit std::int() local, all with Zend-8.4-validated messages ("Division by zero" / "Modulo by zero") and the untouched-target check.

Also updated the PR description with a scope note: binary shifts with typed float operands (double << double, pre-existing invalid C++) are not covered here and belong to the follow-up typed compound-assignment work.