Inference regression for parametric type

[rened]

The reduced example below works on 0.3 and used to work on master until recently - a git bisect leads to b77b026 being the first commit to fail with the following error message:

ERROR: LoadError: MethodError: `convert` has no method matching 
convert(::Type{Sampler{N}}, ::Array{Float64,2}, ::Array{Int64,2}, ::Array{Float64,2})
This may have arisen from a call to the constructor Sampler{N}(...),
since type constructors fall back to convert methods.
Closest candidates are:
  Sampler{N}(::Array{Float64,N}, ::Array{Int64,2}, ::Array{Float64,N})
  call{T}(::Type{T}, ::Any)
  convert{T}(::Type{T}, !Matched::T)
  ...

The code:

type Sampler{N}
    image::Array{Float64,N}
    clampedpos::Array{Int,2}
    buf::Array{Float64,N}
end

repeat(a, n) = map(x->a,1:n)

row(a) = vec(a)'
meshgrid(sm::Int, sn::Int) = meshgrid(1:sm, 1:sn)
meshgrid(rm::AbstractArray, rn::AbstractArray) = [row([m for m in rm, n in rn]); row([n for m in rm, n in rn])]

function Sampler()
    image = rand(200,100)
    bsize = 32

    a = repeat(bsize, 2)
    patchsize = tuple(a...)
    grid = convert(Array{Int},(meshgrid(patchsize...)))

    mi = ones(Int,ndims(image),1) - grid[:,2] + 1
    clampedpos = zeros(Int, size(mi))
    buf = zeros(eltype(image), patchsize)

    Sampler(image, clampedpos, buf)
end
sampler = Sampler()
println("success - got here!")

Interestingly, making this code any simpler (without changing any types) makes it pass again: by e.g. replacing tuple(a...) with (32,32), or removing - grid[:,2], or replacing zeros(Int, size(mi)) with zeros(Int, 2, 1). Tested on OSX and Linux.

[mbauman]

Hm, interesting. I can reproduce and am looking into it. For anyone else looking into things here, the introspection utilities are a little buggy with parametric constructors (#11590). Use: code_warntype(call, Tuple{Type{Sampler}}).

[mbauman]

Alright, well, I haven't found the root cause yet, but a workaround is to use a comprehension for repeat instead of map:

repeat(a, n) = [a for a = 1:n]

[rened]

Just as an update, I kept testing this with master every day, but the issue is still there, so the changes to type caching etc did not affect this. It is interesting that no-one else is reporting similar issues, so perhaps this is a good, repeatable test case for the root cause for this regression.
cc @JeffBezanson

[rened]

I also get this error from time to time in a2ed42c (in a more complex code base), which is 2 weeks older than the b77b026 from the git bisect.

I don't think that this issue is caused by b77b026, the inference / code gen just happens to bump into the issue reliably when using that commit (or a newer one, like current master 0bd3554)

[rened]

@JeffBezanson fantastic! thanks a lot!