type inference problem with captured type in closures

[sbromberger]

function foo(a::AbstractVector)
    T = eltype(a)
    b = Vector{T}()
    c = [Set{T}() for x in a]
    return length(c)
end

a = rand(1:10, 200);

@code_warntype shows an inference failure in b and c.

Changing to c = Set{T}[Set{T}() for x in a] fixes c's inference issue.

[yuyichao]

b is just #23280
c is real and seems to be caused by closure captured type only being specialized on T::DataType.

[ChrisRackauckas]

Is this the same as #15276 ?

[yuyichao]

Depending on what do you call the scope of #15276. Both of these are related to closures but the sources are quite different.

All cases in #15276 are about the frontend not able to tell if a variable can be mutated in the closure/while the closure is executing so it creates a Core.Box for it (the original title was more specific about this). In this case, the lowering correctly determined that the variable doesn't need a Box but it fails to generate code the Type{T} and instead generated/inferred code for DataType.

[sbromberger]

x-ref https://discourse.julialang.org/t/performance-issue-with-use-of-eltype/5764. That is, there is a secondary issue that performance is slow even with explicit typing due to type instability in the inner comprehension loop.

[tkf]

A MWE is:

julia> let f = Int
           typeof(x -> f(x))
       end
var"#51#52"{DataType}

This comes up in ∘ with types:

julia> let f = Int ∘ identity
           @inferred f(1)
       end
ERROR: return type Int64 does not match inferred return type Any
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] top-level scope at REPL[71]:2

A simple workaround is:

julia> begin
       prefer_singleton_callable(::Type{T}) where T = SingletonCallable{T}()
       prefer_singleton_callable(f) = f
       struct SingletonCallable{T} end
       (::SingletonCallable{T})(x) where T = T(x)
       end;

julia> let f = prefer_singleton_callable(Int) ∘ identity
           @inferred f(1)
       end
1

Can this be done during lowering?