too many method matches for zeros(Type, ...)

[simonster]

The underlying cause of #5559 is now fixed, but this was the immediate cause. Before 6002358:

julia> f() = zeros(Type[Float64][1], 1);

julia> code_typed(f, ())
1-element Array{Any,1}:
 :($(Expr(:lambda, {}, {{},{},{}}, quote  # none, line 1:
        return zeros(arrayref(getindex(Type,Float64)::Array{Type{T<:Top},1},1)::Type{T<:Top},1)::Array{T,1}
    end)))

After:

julia> f() = zeros(Type[Float64][1], 1);

julia> code_typed(f, ())
1-element Array{Any,1}:
 :($(Expr(:lambda, {}, {{},{},{}}, quote  # none, line 1:
        return zeros(arrayref(getindex(Type,Float64)::Array{Type{T<:Top},1},1)::Type{T<:Top},1)::AbstractArray{T,N}
    end)))

[JeffBezanson]

This is kind of an "intentional" regression. That change has to be made, in full knowledge that we'll get coarser type information in some cases.

[simonster]

I realize that there will be some cases that regress, but I'm still a little confused about why this regresses. The method list looks like:

julia> methods(zeros, (Type{TypeVar(:T,Top)}, Int))
2-element Array{Any,1}:
 zeros{T}(::Type{T},dims...) at array.jl:201
 zeros(dims...) at array.jl:202 

Shouldn't the top method always match? Why do we need to consider the second method in type inference?

[JeffBezanson]

I have a fix for this that works except for one annoying detail: the default upper bound for a typevar is Any, so Type{<:Top} is not a subtype of the Type{T} in the method definition. zeros(Base.Undef, ...) matches the second definition, which is useless, but computers are pedantic like that :)