`@turbo` behavior change in Julia v1.11: bounds check triggered when using `indices`

[kylincaster]

Dear all,
In Julia v1.10, the following function using @turbo from LoopVectorization.jl runs without error and returns 10:

using LoopVectorization

a = ones(10)
b = ones(11)

@inline function dot(A::AbstractArray{T}, B::AbstractArray{T}) where {T}
    ret = zero(T)
    @turbo for m ∈ indices((A, B), 1)
        ret += A[m] * B[m]
    end
    ret
end

dot(a, b)  # returns 10 in Julia v1.10

However, in Julia v1.11, the same code results in the following error:

ERROR: 10 and 11 are not equal.

This seems to stem from a bounds check triggered deep inside the _static_promote function from Static.jl, likely when evaluating indices((A, B), 1) together with @turbo.

---

Question

• Is this change intentional (i.e., a feature) or a bug?
• In previous versions, @turbo appeared to skip such bounds checks and worked leniently over the shortest matching dimension.
• In Julia v1.11, this stricter behavior is triggered — perhaps correctly — but it may break previous code that relied on implicit truncation via indices.

If this is intended, should users now explicitly write:

for m in 1:min(length(A), length(B))

While the bounds check may lead to more robust behavior, it also breaks backwards compatibility with earlier versions where this function ran fine.

I'd appreciate any clarification on whether this is expected behavior or if it indicates a bug in @turbo or a related change in how indices behaves with StaticArrays.

Thanks in advance!