inline=no causes bizarre BoundsError, which leads to crashes

[dlfivefifty]

The code below causes the following incorrect BoundsError

ERROR: BoundsError: attempt to access 2-element Array{ApproxFun.BandedOperator{Float64},1}: #undef #undef at index [4624888864] in setindex! at array.jl:324 in eval at REPL.jl:3

only when julia 0.4 is called with code-coverage=user, i.e.

julia-debug --check-bounds=yes --code-coverage=user --inline=no --color=yes

I apologize that I haven't been able to narrow down the bug, though I think it is related to Base.convert overrides determining type incorrectly, see the now resolved issue #11874. I am posting the issue now, while I try to come up with a simpler example, in case the fact that code-coverage is triggering it makes it clear what the fix needed is.

Pkg.add("ApproxFun")
using ApproxFun
x=Fun(identity,Ray())
f=-x
D=Derivative(domain(f))
M=Multiplication(f',domainspace(D))
Q=-M
rs=ApproxFun.maxspace(rangespace(D),rangespace(Q))
C=Conversion(rangespace(Q),rs)
A=Array(ApproxFun.BandedOperator{Float64},2)
A[1]=C

[dlfivefifty]

In the meantime, I managed to work around the bug by making sure Base.convert returns the same instance when the type is not changed.

[dlfivefifty]

Actually, I believe the issue is --inline=no

[tkelman]

Is this relevant any more?

@dlfivefifty on your current development branch, the second-to-last line of your example gives TypeError: Type{...} expression: expected Type{T}, got ApproxFun.#BandedOperators. On the v0.2.1 release of ApproxFun, it's notable that due to the change in how https://github.com/ApproxFun/ApproxFun.jl/blob/v0.2.1/src/Spaces/Singularities/JacobiWeightOperators.jl#L251 is parsed, the first line of your example here gives a really nasty error compiling union_rule: unsupported or misplaced expression "&" in function union_rule that's missing the most useful innermost line number information in the backtrace.

[dlfivefifty]

I can't replicate it anymore (I should have made a branch at the time), so let's close the issue.