You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Seven cast rules push nullability casts without trivially_cast_nullability #10750
The cast-rule contract on Validity::cast_nullability (vortex-array/src/validity.rs) asks a CastReduce rule to call Validity::trivially_cast_nullability, to return Ok(None) when that call cannot prove a nullability cast safe, and to pair the rule with a CastKernel for execution. These cast rules instead push a nullability cast into the child that holds their validity, with no guard:
Encoding
Rule
Child
RunEnd
encodings/runend/src/compute/cast.rs
values
ZigZag
encodings/zigzag/src/compute/cast.rs
encoded
FoR
encodings/fastlanes/src/for_/compute/cast.rs
encoded
RLE
encodings/fastlanes/src/rle/compute/cast.rs
indices
ALP
encodings/alp/src/alp/compute/cast.rs
encoded
ALP-RD
encodings/alp/src/alp_rd/compute/cast.rs
left parts
DateTimeParts
encodings/datetime-parts/src/compute/cast.rs
days
From reading the code, no wrong result is visible today, because the null check still runs when the child cast executes. The rules depend on every child cast keeping that check, though. DecimalByteParts had the same gap, and #10746 fixes it with the guard plus a CastKernel.
Proposed solution
Apply the DecimalByteParts fix to each rule: guard it with trivially_cast_nullability, add a CastKernel for the case that needs execution, and test nullable to non-nullable casts with nulls, without nulls and with only nulls. A shared helper for "push a nullability cast into the validity child" can avoid seven copies of the guard.
Open question: does the contract apply to rules that do not inspect validity themselves? The contract asks for a kernel only from rules that do.
Additional context
Found while planning #10701. Research notes: #10633.
Activity