`intersect(::StepRange, ::StepRange)` silently overflows producing strange incorrect answers

[LilithHafner]

julia> a, b = StepRange{Int8, Int8}.((-56:121:-56, 35:62:34))
(-56:121:-56, 35:62:34)

julia> intersect(a,b)
-56:121:65

julia> collect(a), collect(b), collect(intersect(a, b))
(Int8[-56], Int8[], Int8[-56, 65])

julia> invoke(intersect, Tuple{AbstractArray, AbstractArray}, a, b)
Int8[]

Behavior is identical on 1.8 & master.

I believe the bug is here in range.jl

function intersect(r::StepRange, s::StepRange)
    T = promote_type(eltype(r), eltype(s))
    S = promote_type(typeof(step(r)), typeof(step(s)))
    if isempty(r) || isempty(s)
        return StepRange{T,S}(first(r), step(r), first(r)-step(r))
    end

    start1, step1, stop1 = first_step_last_ascending(r)
    start2, step2, stop2 = first_step_last_ascending(s)
    a = lcm(step1, step2)    ###   <-----------   overflow here is more common and errors rather than giving wrong results

    g, x, y = gcdx(step1, step2)

    if !iszero(rem(start1 - start2, g))
        # Unaligned, no overlap possible.
        if  step(r) < zero(step(r))
            return StepRange{T,S}(stop1, -a, stop1+a)
        else
            return StepRange{T,S}(start1, a, start1-a)
        end
    end

    z = div(start1 - start2, g)
    b = start1 - x * z * step1    ###   <---------------------------- overflow at this line is silent
    # Possible points of the intersection of r and s are
    # ..., b-2a, b-a, b, b+a, b+2a, ...
    # Determine where in the sequence to start and stop.
    m = max(start1 + mod(b - start1, a), start2 + mod(b - start2, a))
    n = min(stop1 - mod(stop1 - b, a), stop2 - mod(stop2 - b, a))
    step(r) < zero(step(r)) ? StepRange{T,S}(n, -a, m) : StepRange{T,S}(m, a, n)
end

[Moelf]

I can give this a try, do you know what might be a preferred way of fixing? I see two possibilities:

1. widen types in intermediate steps
2. use Base.checked_add and Base.checked_mul

[LilithHafner]

I think checked arithmetic and errors is fine because it will have better performance for large integer types. Ideally we don't introduce errors where we used to get right answers.

An ideal solution would be to be clever and get the right answer for all inputs without using wider intermediate steps, but that ideal solution should not stop you from fixing the correctness bug by throwing errors.