map gives different result than applying function separately only on nightly

[felixcremer]

On nightly on 1.13.0-DEV.213 and 1.13.0-DEV.331 we get very broken results on applying a function via map in contrast to applying the function on all elements that go into map.
This works as expected in Julia 1.11.4
See rafaqz/DimensionalData.jl#965 for the details, but I managed to condense it to the following MWE.

Interestingly the result is correct when I add some @show statements in the _format function.

julia> using DimensionalData

julia> a = ones(5, 4)
5×4 Matrix{Float64}:
 1.0  1.0  1.0  1.0
 1.0  1.0  1.0  1.0
 1.0  1.0  1.0  1.0
 1.0  1.0  1.0  1.0
 1.0  1.0  1.0  1.0

julia> di = X(LinRange(140, 148, 5)), Y(LinRange(2, 11, 4))
(↓ X LinRange{Float64}(140.0, 148.0, 5),
→ Y LinRange{Float64}(2.0, 11.0, 4))

julia> map(DimensionalData.Dimensions._format, di, axes(a))
rdim = X{DimensionalData.Dimensions.Lookups.Sampled{Float64, LinRange{Float64, Int64}, DimensionalData.Dimensions.Lookups.ForwardOrdered, DimensionalData.Dimensions.Lookups.Regular{Float64}, DimensionalData.Dimensions.Lookups.Points, DimensionalData.Dimensions.Lookups.NoMetadata}}([140.0, 142.0, 144.0, 146.0, 148.0])
rdim = Y{DimensionalData.Dimensions.Lookups.Sampled{Float64, LinRange{Float64, Int64}, DimensionalData.Dimensions.Lookups.ForwardOrdered, DimensionalData.Dimensions.Lookups.Regular{Float64}, DimensionalData.Dimensions.Lookups.Points, DimensionalData.Dimensions.Lookups.NoMetadata}}([2.0, 5.0, 8.0, 11.0])
(↓ X Sampled{Float64} LinRange{Float64}(140.0, 148.0, 5) ForwardOrdered Regular Points,
→ Y Sampled{Float64} LinRange{Float64}(6.830797958345e-310, 5.0e-324, 4096) ForwardOrdered Regular Points)
# Expected result for the second element:
julia> [DimensionalData.Dimensions._format(di[i], axes(a)[i]) for i in eachindex(di)][2]
Y Sampled{Float64} ForwardOrdered Regular DimensionalData.Dimensions.Lookups.Points
wrapping: 4-element LinRange{Float64, Int64}:
 2.0, 5.0, 8.0, 11.0

[adienes]

bisected to #52850

[adienes]

here's a self-contained reproducer

struct Q{T}
    val::T
end

di = Q(LinRange(140, 148, 5)), Q(LinRange(2, 11, 4));

struct AutoValues <: AbstractVector{Int} end
struct AutoOrder end
struct AutoSpan end

struct Sampled{T, A <: AbstractVector{T}, O, Sp}
    data::A
    order::O
    span::Sp
end
function Sampled(
        data = AutoValues();
        order = AutoOrder(), span = AutoSpan(),
    )
    return Sampled(data, order, span)
end

function rebuild_local(
        l::Sampled;
        data = nothing, order = nothing, span = nothing, metadata = nothing, kw...
    )
    return Sampled(data, order, span)
end

module LookupLocal
    struct ForwardOrderedLocal end
    struct ReverseOrderedLocal end
    orderof_local(A::AbstractRange) = _order_local(A)
    _order_local(A) = first(A) <= last(A) ? ForwardOrderedLocal() : ReverseOrderedLocal()
end

function format_local(m::Sampled, D::Type, values)
    o = LookupLocal.orderof_local(values)
    sp = AutoSpan()
    x = rebuild_local(m; data = values, order = o, span = sp)
    return x
end

bar(t) = (
    format_local(Sampled(), Q, t[1].val),
    Q(format_local(Sampled(), Q, t[2].val)),
)
bar(di)[2].val

there is some incredibly funky stuff happening. the problem goes away if any of

• the kw... is removed from rebuild_local
• the unused metadata=nothing is removed from rebuild_local
• the LookupLocal methods are extracted to top level
• the bar function only calls format_local once
• the bar function does not call the final conversion to Q

and probably a lot more tiny perturbations will fix the issue

[adienes]

note that this should probably just error --- and in fact I think the existing DimensionalData.Dimensions.Sampled constructor is actually malformed (re: data as the only default-assigned positional argument and the others are keywords, but in rebuild they are all passed in positionally)

[gbaraldi]

This is already very helpful

[gbaraldi]

This looks like it's an LLVM bug, filed upstream. Will let it sit for a bit and if nobody bites I think me and @vtjnash have some ideas as to how to fix it

[gbaraldi]

llvm/llvm-project#135615 will ne to be ported back (or we go to llvm 20 where it looks like it's going to be on the normal branch)

[oscardssmith]

Does this bug exist on 1.12? If so, we need a backport.

[gbaraldi]

Doesn't look like it