Type stability issue in rfft

[andreasnoack]

Both on 0.3 and 0.4 I get return Any for Vector{Float64} input, e.g.

julia> @code_typed rfft(randn(10))
1-element Array{Any,1}:
 :($(Expr(:lambda, Any[:X], Any[Any[],Any[Any[:X,Array{Float64,1},0]],Any[]], :(begin  # fftw.jl, line 639:
        return rfft(X::Array{Float64,1},$(Expr(:new, UnitRange{Int64}, 1, :(((top(getfield))(Intrinsics,:select_value))((top(sle_int))(1,1)::Bool,1,(top(box))(Int64,(top(sub_int))(1,1)))::Int64))))::Any
    end::Any))))

The other fft methods seem to be okay.

See also https://groups.google.com/forum/#!searchin/julia-users/rfft/julia-users/hmDHPknmlIA/lneRvuxU4PcJ

cc: @stevengj

[stevengj]

Seems to be a problem in type inference for plan_rfft; I will try to fix it on my new-API branch (#6193), where the same problem occurs.

Is there an easy way to automate a test for this kind of failed type inference?

[andreasnoack]

If there is, I'd like to know. It can be hard to notice that you accidentally breaks type stability for a method.

[simonster]

@inferred f(x) (in Base.Test) will ensure that the type returned by f(x) matches what type inference for those argument types and also pass through the result, e.g.:

julia> @inferred getindex([1], 1)
1

julia> @inferred getindex(Any[1], 1)
ERROR: return type Int64 does not match inferred return type Any
 in error at error.jl:21

[stevengj]

Ah, good to know.