Fix linear indexing for ReshapedArray if the parent has offset axes

[jishnub]

Fixes #39953

Currently a ReshapedArray is too permissive, and it acts as an offset-free wrapper if the parent is an offset array.

julia> r = Base.IdentityUnitRange(0:1)
Base.IdentityUnitRange(0:1)

julia> reshape(r, (2,1))
2×1 reshape(::Base.IdentityUnitRange{UnitRange{Int64}}, 2, 1) with eltype Int64:
 0
 1

This causes multiple problems -- firstly linear indexing is broken for such an array (#39953). Secondly, if a 1D offset array is wrapped in a 2D ReshapedArray, calling vec on it fails, as the operation is a reshape on the parent which does not have 1-based indices.

julia> reshape(r, (2,1)) |> vec
ERROR: ArgumentError: offset arrays are not supported but got an array with index other than 1
Stacktrace:
 [1] require_one_based_indexing
   @ ./abstractarray.jl:110 [inlined]
 [2] _reshape
   @ ./reshapedarray.jl:168 [inlined]
 [3] _reshape
   @ ./reshapedarray.jl:186 [inlined]
 [4] reshape
   @ ./reshapedarray.jl:112 [inlined]
 [5] reshape
   @ ./reshapedarray.jl:116 [inlined]
 [6] vec
   @ ./abstractarraymath.jl:41 [inlined]
 [7] |>(x::Base.ReshapedArray{Int64, 2, Base.IdentityUnitRange{UnitRange{Int64}}, Tuple{}}, f::typeof(vec))
   @ Base ./operators.jl:966
 [8] top-level scope
   @ REPL[6]:1

While the linear indexing may be fixed by adding appropriate offsets to the indices, fixing all the problems associated with this might be more difficult.

This PR makes reshaping an offset array illegal. A custom offset array type should define its own reshape method to specify what's to be done with the axes offsets. Often, eg. in OffsetArrays, the reshape may be translated to the parent, and new offsets may be wrapped around the result.

This PR fixes the linear indexing issue. The vec one is not resolved.

[mcabbott]

it acts as an offset-free wrapper

Isn't this what it should do? Once you have offsets around, similar(o, Int, (2,)) is best viewed as shorthand for similar(o, Int, (Base.OneTo(2),)), and likewise reshape(o, 2). That's what happens in these examples, which this PR would (I think) make into errors?

julia> ot = OffsetArray(rand(Int8,3,2),1,10)'
2×3 adjoint(OffsetArray(::Matrix{Int8}, 2:4, 11:12)) with eltype Int8 with indices 11:12×2:4:
 -121   53  -16
   88  118   43

julia> ot[1], ot[5] # linear indexing
(-121, -16)

julia> vec(ot)[1], vec(ot)[5]
(-121, -16)

julia> reshape(ot, 3,2)
3×2 reshape(adjoint(OffsetArray(::Matrix{Int8}, 2:4, 11:12)), 3, 2) with eltype Int8:
 -121  118
   88  -16
   53   43

julia> ans[1]
-121

julia> @which reshape(ot, 3,2)  # does not require OffsetArrays to overload all possible wrappers, just works
reshape(parent::AbstractArray, dims::Int64...) in Base at reshapedarray.jl:116

Likewise for 1D offset arrays:

julia> o = OffsetArray(rand(Int8,4),10)
4-element OffsetArray(::Vector{Int8}, 11:14) with eltype Int8 with indices 11:14:
  -90
  -89
 -103
  127

julia> rm = reshape(o,2,2)  # this is what was requested
2×2 Matrix{Int8}:
 -90  -103
 -89   127

julia> rm[1]
-90

julia> rv = reshape(view(o,:),2,2)
2×2 reshape(view(OffsetArray(::Vector{Int8}, 11:14), :), 2, 2) with eltype Int8:
 -90  -103
 -89   127
 
julia> rv[1]  # that's a bug, surely
0

Can't the linear indexing bug be fixed without breaking these other things?

[jishnub]

Good point, I had overlooked this. The linear indexing bug is easy to fix, and was my original plan. The vec is harder to fix, but that may be addressed separately

[jishnub]

For easier review, this PR currently only fixes

julia> r = reshape(Base.IdentityUnitRange(3:4), 2, 1)
2×1 reshape(::Base.IdentityUnitRange{UnitRange{Int64}}, 2, 1) with eltype Int64:
 3
 4

julia> collect(r) == r
false

julia> collect(r)
2×1 Matrix{Int64}:
 3258125826116431922
 3688512103538242609

After this PR,

julia> collect(r)
2×1 Matrix{Int64}:
 3
 4