Fix test failures across the whole CI matrix

[davidanthoff]

Every run-tests leg of CI is currently red — 78/78 on the last PR run and on main. Three of the 13 test items fail. None of it is fallout from the test-item migration; these are long-standing bugs that the migration surfaced, plus one test that has been comparing floats for bit equality since Julia 1.0.

Which items fail depends on the Julia version:

Julia	Failing items
1.0 – 1.5	Reduce
1.6 – 1.13-rc	Reduce, Primitives, DataVector

What changed in Base, and when

Every version in the CI matrix was probed locally through its juliaup channel, so each fix targets a known boundary rather than a runtime feature check — no @static, no isdefined branches:

Julia	Base._growbeg!	ccall(:jl_array_grow_beg)	Base._prepend! 1st arg	Base.reverse(::AbstractVector, _, _)
1.0.5 – 1.5.4	✓	works	Any	Any, Any
1.6.7 – 1.9.4	✓	works	Any	Integer, Integer
1.10.12	✓	works	Vector	Integer, Integer
1.11.9 – 1.13.0-rc3	✓	symbol gone	Vector	Integer, Integer

The four source bugs

jl_array_grow_beg is gone from Julia 1.11 on. The three ccalls in datavaluevector.jl die with "could not load symbol". Replaced with Base._growbeg!, the Base wrapper that has always sat in front of that symbol — present with the same signature and identical behaviour on 1.0.5 through 1.13.0-rc3 (checked functionally at both ends, with Vector{Int} and Vector{Bool}). The same file already uses Base._growat! and Base._deleteat!.

Multi-value pushfirst! broke in Julia 1.10. pushfirst!(X, a, b, c) reaches us as prepend!(X, (a, b, c)), whose Base fallback narrowed from Any to Vector. Added a general-iterable prepend! beside the existing AbstractVector method; [x for x in items] always yields a Vector, so it cannot recurse.

reverse/reverse! became ambiguous in Julia 1.6, when Base typed its own positional arguments as Integer while ours stayed untyped. Typed ours to match — strictly more specific on 1.6+, and equally unambiguous against the pre-1.6 untyped method. Their docstrings also claimed (start, count) semantics while the bodies always forwarded Base's (start, stop); corrected.

promote_type(Any, DataValue{T}) overflowed the stack. Base's missing.jl defines promote_rule(T::Type{>:Union{Missing,Nothing}}, S::Type) = Any, so for (Any, DataValue{Any}) the two directions disagree — Base says Any, we say DataValue{Any} — and promote_result re-asks the same question forever. Added the mirror-image rule so both directions agree, keeping the DataValue{Any} answer. Every promotion case asserted in test_basederived.jl and test_core.jl is unchanged. This was latent anywhere Any met a DataValue in promotion, e.g. reduce(promote_type, ...) over column types in QueryOperators' pivot.

The test bug

Reduce compared a DataValueArray reduction against Base's for bit equality. Base's mapreduce_impl over a Vector{Float64} uses @simd and reassociates; accumulating DataValues cannot vectorise and stays strictly sequential, so at N = 2050 the two differ by exactly 1 ULP (5091.29121864207 vs 5091.291218642071). That has failed on every version since 1.0. Rather than relax the assertions, the data is now drawn from integers ≤ 1000, so every partial sum is exactly representable and reassociation cannot change the result — the four isequal/== comparisons stay exact. Keeping Float64 storage leaves the six DataValue{Float64}() expectations untouched.

Verification

13/13 items pass on 1.0.5, 1.6.7, 1.10.12, 1.11.9, 1.12.7 and 1.13.0-rc3 — both sides of every Base transition in the table above.

No Project.toml change: the version is already the unreleased 1.0.0-DEV, and julia = "1" still holds.

🤖 Generated with Claude Code