[SPARK-59639][SQL] Tighten nullability of Divide, Remainder, IntegralDivide, and Pmod under ANSI mode

[david-mollitor-db]

What changes were proposed in this pull request?

Divide, Remainder, and IntegralDivide (which share the DivModLike trait) and Pmod declared override def nullable: Boolean = true unconditionally. This PR makes nullable reflect what the operators can actually produce at runtime:

override def nullable: Boolean = left.nullable || right.nullable || !failOnError

Under ANSI mode (failOnError), divide-by-zero and integral overflow throw rather than returning null, so the result is null only when one of the inputs is null. Under LEGACY/TRY mode the behavior is unchanged (nullable stays effectively true), because divide-by-zero returns null there and, for decimals, a precision overflow can also return null independent of the divisor.

A follow-up commit also updates DivModLike.doGenCode / Pmod.doGenCode: when the expression is now non-nullable they no longer emit the boolean isNull = false; declaration (which had become a dead store, plus a dead local that widened the StackMapTable frames covering its scope) and instead report FalseLiteral — mirroring the existing MakeDecimal / CheckOverflow codegen. eval semantics are untouched.

Why are the changes needed?

Whole-stage and expression code generation represent SQL NULL with boolean isNull flags. A nullable = true child forces the framework to materialize an isNull variable and makes every parent expression emit a null-guard branch on it (CodegenContext.nullSafeExec). Because nullability propagates, a single spuriously-nullable % / / / pmod cascades dead if (!isNull) branches into the comparisons, CASE WHENs, and predicates built on top of it.

For example, (id % 2) = 0 inside a CASE WHEN (ANSI) generated:

boolean project_isNull_5 = false;          // id % 2 -- never set to true
if (!project_isNull_5) { ... }             // dead guard
...
if (!project_isNull_4 && project_value_4)  // dead: !isNull_4 is always true here

Correcting the nullability removes these dead guards at the source and feeds more accurate nullability to the optimizer; the codegen follow-up additionally removes the now-dead isNull = false stores.

Beyond cleaner code, this has a JIT dimension. HotSpot does not JIT-compile a method whose bytecode exceeds -XX:HugeMethodLimit (default 8000 bytes) — such a method runs in the interpreter. The per-operation isNull flags, null-guard branches, and dead stores inflate the bytecode of exactly the arithmetic-heavy generated methods that sit closest to this limit. On a set of representative codegen-heavy projections, the largest generated method dropped from ~9.1 KB (above the limit, interpreter-only) to ~7.7 KB (JIT-compiled) with this change.

Does this PR introduce any user-facing change?

Yes (schema metadata only). Under ANSI mode, an output column that is a /, %, div, or pmod over non-nullable inputs is now reported as non-nullable, whereas before it was reported as nullable. Computed values and error behavior are unchanged: ANSI divide/remainder/pmod-by-zero and integral overflow still throw, and LEGACY/TRY still return null.

• Before: spark.range(1).selectExpr("id % 2").schema.head.nullable is true
• After (ANSI): the same is false

How was this patch tested?

Existing suites, all pass with no golden-file changes:

• ArithmeticExpressionSuite, PredicateSuite, ColumnExpressionSuite
• SQLQueryTestSuite: operators.sql, try_arithmetic.sql, decimalArithmeticOperations.sql

.sql.out golden files are unaffected because their schema lines use df.schema.catalogString, which does not encode nullability. The codegen changes were additionally verified by inspecting generated bytecode: the dead isNull guards and stores for % / / / pmod over non-null inputs are gone under ANSI (LEGACY/TRY are unchanged).

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Isaac

This pull request and its description were written by Isaac.