Inconsistent type inference for getindex(BitArray{2}, Int64, Range1{Int64})

[simonster]

There's a test in DataFrames that's intermittently failing due to something that looks like an inference bug. When I run finfer(getindex, (BitArray{2}, Int64, Range1{Int64})) immediately after starting Julia, I sometimes get:

finfer(getindex, (BitArray{2}, Int64, Range1{Int64}))
:($(Expr(:lambda, {:B, :(I::top(apply_type)(Vararg,Union(Real,AbstractVector)))}, {{:X, :Xc}, {{:B, BitArray{2}, 0}, {:I, Any, 2}, {:X, BitArray{2}, 2}, {:Xc, Array{Uint64,1}, 2}}, {{:getindex_cache, Any, 7}}}, quote  # bitarray.jl, line 471:
        I = top(tuple)(indices(tupleref(I::(Int64,Range1{Int64}),1)::Union(Range1{Int64},Int64)),indices(tupleref(I::(Int64,Range1{Int64}),2)::Union(Range1{Int64},Int64)))::(Any,Any) # line 472:
        X = BitArray(index_shape(top(tupleref)(I::(Any,Any),1),top(tupleref)(I::(Any,Any),2))::Union((),(Any,),(Any,Any)))::BitArray{2} # line 473:
        Xc = top(getfield)(X::BitArray{2},:chunks)::Array{Uint64,1} # line 475:
        unless is(getindex_cache,nothing)::Bool goto 0 # line 476:
        getindex_cache = $(Dict{Any,Any})()::Dict{Any,Any}
        0:  # line 478:
        gen_cartesian_map(getindex_cache,$(AST(:($(Expr(:lambda, {:(ivars::Any)}, {{:#s143, :#s137}, {{:ivars, Any, 0}, {:#s143, Array{Any,1}, 2}, {:#s137, Array{Any,1}, 2}}, {}}, quote  # bitarray.jl, line 478:
        #s143 = top(ccall)(:jl_alloc_array_1d,$(Array{Any,1}),top(tuple)(Any,Int)::(Type{Any},Type{Int64}),$(Array{Any,1}),0,1,0)::Array{Any,1}
        top(arrayset)(#s143::Array{Any,1},:B,1)::Array{Any,1}
        #s137 = #s143::Array{Any,1}
        return top(Expr)(:block,top(Expr)(:line,480,:bitarray.jl)::Expr,top(Expr)(:call,:setindex_unchecked,:Xc,top(splicedexpr)(:ref,top(append_any)(#s137::Array{Any,1},ivars)::Array{Any,1})::Expr,:ind)::Expr,top(Expr)(:line,481)::Expr,top(Expr)(:+=,:ind,1)::Expr)::Expr
    end))))),I::(Any,Any),top(tuple)(:B,:Xc,:ind)::(Symbol,Symbol,Symbol),B::BitArray{2},Xc::Array{Uint64,1},1) # line 483:
        return X::BitArray{2}
    end)))

which looks okay. Other times I get:

finfer(getindex, (BitArray{2}, Int64, Range1{Int64}))
:($(Expr(:lambda, {:B, :(I::top(apply_type)(Vararg,Union(Real,AbstractVector)))}, {{:X, :Xc}, {{:B, BitArray{2}, 0}, {:I, Any, 2}, {:X, BitArray{1}, 2}, {:Xc, Array{Uint64,1}, 2}}, {{:getindex_cache, Any, 7}}}, quote  # bitarray.jl, line 471:
        I = top(tuple)(indices(tupleref(I::(Int64,Range1{Int64}),1)::Union(Int64,Range1{Int64})),indices(tupleref(I::(Int64,Range1{Int64}),2)::Union(Int64,Range1{Int64})))::(Any,Any) # line 472:
        X = BitArray(index_shape(top(tupleref)(I::(Any,Any),1),top(tupleref)(I::(Any,Any),2))::Union((),(Any,Any),(Any,)))::BitArray{1} # line 473:
        Xc = top(getfield)(X::BitArray{1},:chunks)::Array{Uint64,1} # line 475:
        unless is(getindex_cache,nothing)::Bool goto 0 # line 476:
        getindex_cache = $(Dict{Any,Any})()::Dict{Any,Any}
        0:  # line 478:
        gen_cartesian_map(getindex_cache,$(AST(:($(Expr(:lambda, {:(ivars::Any)}, {{:#s143, :#s137}, {{:ivars, Any, 0}, {:#s143, Array{Any,1}, 2}, {:#s137, Array{Any,1}, 2}}, {}}, quote  # bitarray.jl, line 478:
        #s143 = top(ccall)(:jl_alloc_array_1d,$(Array{Any,1}),top(tuple)(Any,Int)::(Type{Any},Type{Int64}),$(Array{Any,1}),0,1,0)::Array{Any,1}
        top(arrayset)(#s143::Array{Any,1},:B,1)::Array{Any,1}
        #s137 = #s143::Array{Any,1}
        return top(Expr)(:block,top(Expr)(:line,480,:bitarray.jl)::Expr,top(Expr)(:call,:setindex_unchecked,:Xc,top(splicedexpr)(:ref,top(append_any)(#s137::Array{Any,1},ivars)::Array{Any,1})::Expr,:ind)::Expr,top(Expr)(:line,481)::Expr,top(Expr)(:+=,:ind,1)::Expr)::Expr
    end))))),I::(Any,Any),top(tuple)(:B,:Xc,:ind)::(Symbol,Symbol,Symbol),B::BitArray{2},Xc::Array{Uint64,1},1) # line 483:
        return X::BitArray{1}
    end)))

which gives the wrong return type.

[JeffBezanson]

same root cause as #3167

[simonster]

Should this be closed? The symptoms here are definitely gone, although it's unclear to me whether the underlying issue is fixed.

[pao]

If the underlying issue is #3167, this should be safe to close as duplicate, unless the thought is the root cause isn't in fact the same.

[quinnj]

Closing as dup of #3167