Types::Numbers fails to load with Not a SCALAR reference

[fglock]

Summary

The DBIx::BatchChunker v1.0.2 CPAN compatibility run fails while loading the distribution. The failure reduces to importing Types::Numbers v1.0.1, which raises Not a SCALAR reference under both PerlOnJava execution backends.

Minimal reproducer

#!/usr/bin/env perl
use strict;
use warnings;

use Types::Numbers;

print "Types::Numbers loaded successfully\n";

Expected output:

Types::Numbers loaded successfully

Results

• System Perl: passes and prints the expected output.
• PerlOnJava JVM backend: exits 255 with Not a SCALAR reference at (eval 222) line 98.
• PerlOnJava interpreter backend: exits 255 with the same error.

The reproducer is also retained in the repository as dev/sandbox/reproducers/dbix_batchchunker_types_numbers.pl.

Original CPAN failure

• Distribution: DBIx::BatchChunker v1.0.2
• CPAN run: 20260902-193404-39801
• Result: 2/3 subtests failed; 8/12 test programs failed
• Both DBIx::BatchChunker and DBIx::BatchChunker::LoopState failed their compile/load checks with Not a SCALAR reference.
• The failure occurs during module loading, before the database behavior tests can execute.

The target distribution is pure Perl. Its dependency chain includes Types::Numbers, Type::Tiny, Moo, and database-related modules. System Perl successfully loads the target modules after the missing prerequisites are installed in an isolated environment. Some DB integration tests require a file-backed SQLite DSN because the upstream tests create a second connection to an in-memory database; that setup issue is separate from this deterministic module-load failure.

Suspected ownership

The first failing dependency is Types::Numbers, not DBIx::BatchChunker itself. The error likely involves compiler/runtime handling of a scalar reference or generated Type::Tiny/Moo code. The failure is present on both backends, so it should be investigated in shared parsing/compiler/runtime behavior rather than only one backend.

This does not currently appear to be a regex-engine defect: the reducer fails during module initialization, and no regex matching operation is required to trigger it.

Requested fix and coverage

1. Inspect the generated/evaluated code path used while Types::Numbers initializes its Type::Tiny definitions.
2. Reduce Not a SCALAR reference to the smallest Perl construct, identifying whether the cause is scalar-reference dereferencing, closure/code generation, type-library initialization, or runtime value representation.
3. Add a focused project-owned regression test for the reduced construct.
4. Verify system Perl, JVM PerlOnJava, and interpreter PerlOnJava behavior.
5. Re-run DBIx::BatchChunker v1.0.2 as post-fix CPAN coverage.

[fglock]

Deeper investigation: reduced to Data::Float

The failure reduces one dependency level below Types::Numbers, to Data::Float v0.015.

Minimal failing operation:

use Data::Float;
Data::Float::float_is_infinite(1.0);

Results:

• System Perl: succeeds.
• PerlOnJava JVM backend: exits 255 with Not a SCALAR reference.
• PerlOnJava interpreter backend: exits 255 with the same error.

Other Data::Float operations succeed under PerlOnJava, including max_integer, mult_pow2, pow2, float_is_zero, and float_is_nan.

The failing call chain during Types::Numbers initialization is:

Types::Numbers
  -> Data::Float::float_parts(Data::Float::max_integer)
  -> float_is_nzfinite()
  -> float_is_infinite()

Data::Float defines the affected functions by evaluating its __DATA__ section at runtime. The reported (eval) line 98 maps to:

return $val == $pos_infinity || $val == $neg_infinity;

$pos_infinity and $neg_infinity are lexicals captured from the surrounding module initialization. This strongly points to a shared eval STRING lexical-capture or scalar-value representation bug. It does not currently look like a regex-engine issue: no regex operation is needed for the minimal failure, and the failing function only compares its argument with captured infinity values.

The project-owned reducer is committed as dev/sandbox/reproducers/dbix_batchchunker_types_numbers.pl. The original CPAN impact remains DBIx::BatchChunker v1.0.2 failing 2/3 subtests and 8/12 test programs in run 20260902-193404-39801.

Suggested next step: reduce the Data::Float pattern to a small project-owned test covering a string-evaluated function that compares an argument with captured lexical scalar values, then fix and verify both PerlOnJava backends.