@report_opt reports runtime dispatch on abstract keyword arguments

[dpinol]

Hi,
the following base code causes a dispatch report.

struct S
    v::Vector
    S(;v) = new(v)
end
const s1=S(v=[3])

f(s::S) = S(v=s.v)
@report_opt f(s1)
═════ 1 possible error found ═════
┌ @ REPL[4]:1 NamedTuple{(:v,)}(%2)
│ runtime dispatch detected: NamedTuple{(:v,)}(%2::Tuple{Vector})
└─────────────

g() = f(s1)
@report_opt g()

However, variations with directly creating the S instance (V1) or doing it through 2 intermediate functions (V2) do not cause any report.

struct S
    v::Vector
    S(;v) = new(v)
end
const s1=S(v=[3])

f(s::S) = S(v=s.v)

@report_opt S(v=s1.v)
g() = f(s1)
@report_opt g()

With this variation V3 (normal argument instead of kwargs), I don't get any report either.

struct S
    v::Vector
    S(v) = new(v)
end
const s1=S([3])

f(s::S) = S(s.v)
@report_opt f(s1)

This final variation V4, identical to the first one, but running within a module I don't get any report either.

module Arg
using JET
struct S
    v::Vector
    S(;v) = new(v)
end
const s1=S(v=[3])

f(s::S) = S(v=s.v)
@report_opt f(s1)
end

Are all these results expected? If the dispatch reported by the original case is a true positive, is there a way to avoid it (apart from not using kwargs for the constructor and defining the field with a concrete type?)

thanks

[aviatesk]

Are all these results expected?

It's not a false positive. In general, what report_opt reports should really reflect how Julia compiler fails to optimize your code.

The implementation of keyword argument scheme uses NamedTuple, which always tries to specialize inputs, and thus causes runtime dispatch if the input is abstract.

If you embed a global constant (like g() = f(s1)), Julia compiler may be able to constant fold it. This is why JET doesn't report the error for such cases.

[dpinol]

thanks for your quick reply!

The implementation of keyword argument scheme uses NamedTuple, which always tries to specialize inputs, and thus causes runtime dispatch if the input is abstract.

This is unfortunate, as kw arguments make code much more robust and readable.

[aviatesk]

Yeah, it might make sense to allow @nospecialize to work with keyword arguments, like:

function kwIsType(; @nospecialize(a = nothing))
    isa(a, DataType) && a.name === Type.body.name
end

Maybe you want to file an issue at JuilaLang/julia ?

[dpinol]

I will, thanks for the hint! 👍