How do I identify a problem flagged by JET.JL?

90 views Asked by At

I started using JET.jl recently. In most cases it is helpful. However, sometimes I just cannot figure out why it has a problem with my code. An example is below. The function foo is very basic and works fine. Still, JET.jl’s macro @report_call reports an error. I cannot figure out what it is. What is the best way to identify the problem using the information provided by the macro call?

using DataFrames, JET
df = DataFrame(:A => [1.0, 2.0, 3.0, 4.0])
# 4×1 DataFrame
# Row │ A       
#     │ Float64
# ─────┼─────────
#  1 │     1.0
#  2 │     2.0
#  3 │     3.0
#  4 │     4.0

function foo(df::DataFrame)::DataFrame
    v = 1:nrow(df)
    df[!, :B] = v

    return df
end
# foo (generic function with 1 method)

foo(df)
# 4×2 DataFrame
# Row │ A        B     
#     │ Float64  Int64
# ─────┼────────────────
#   1 │     1.0      1
#   2 │     2.0      2
#   3 │     3.0      3
#   4 │     4.0      4

julia> @report_call foo(df)
═════ 1 possible error found ═════
┌ @ REPL[20]:3 df[:, :B] = v
│┌ @ C:\Users\fsald\.julia\packages\DataFrames\Lrd7K\src\dataframe\dataframe.jl:721 df[DataFrames.:!, col_ind] = DataFrames.copy(v)
││┌ @ C:\Users\fsald\.julia\packages\DataFrames\Lrd7K\src\dataframe\dataframe.jl:669 DataFrames.insert_single_column!(df, v, col_ind)
│││┌ @ C:\Users\fsald\.julia\packages\DataFrames\Lrd7K\src\dataframe\dataframe.jl:653 DataFrames._drop_all_nonnote_metadata!(df)
││││┌ @ C:\Users\fsald\.julia\packages\DataFrames\Lrd7K\src\other\metadata.jl:759 DataFrames._drop_table_nonnote_metadata!(df)
│││││┌ @ C:\Users\fsald\.julia\packages\DataFrames\Lrd7K\src\other\metadata.jl:752  = iterate(metadatakeys(df), getfield(_3, 2))
││││││┌ @ tuple.jl:68 t[i]
│││││││┌ @ tuple.jl:29 Base.getfield(t, i, $(Expr(:boundscheck)))
││││││││ invalid builtin function call
2

There are 2 answers

0
Bogumił Kamiński On BEST ANSWER

The problem seems to be related to JET.jl not handling correctly type unstable code with small type union. Here is an example:

julia> function f()
           x = rand(Bool) ? () : (1,)
           for v in x
               println(v)
           end
       end
f (generic function with 1 method)

julia> @report_call f()
═════ 1 possible error found ═════
┌ @ REPL[26]:5  = iterate(x, getfield(_2, 2))
│┌ @ tuple.jl:68 t[i]
││┌ @ tuple.jl:29 Base.getfield(t, i, $(Expr(:boundscheck)))
│││ invalid builtin function call: Base.getfield(t::Tuple{}, i::Int64, $(Expr(:boundscheck)))
││└───────────────

I reported it at https://github.com/aviatesk/JET.jl/issues/404

1
Bill On

I had no error using DataFrames v1.3.6, but with updating DataFrames to your version DataFrames v1.4.1 I got this error:

julia> @report_call foo(df)
═════ 1 possible error found ═════
┌ @ REPL[9]:3 Base.materialize!(Base.dotview(df, !, :B), Base.broadcasted(identity, v))
│┌ @ broadcast.jl:868 Base.Broadcast.materialize!(Base.Broadcast.combine_styles(dest, bc), dest, bc)
││┌ @ broadcast.jl:871 Base.Broadcast.copyto!(dest, Base.Broadcast.instantiate(Base.Broadcast.Broadcasted{Base.Broadcast.DefaultArrayStyle{1}}(bc.f, bc.args, Base.Broadcast.axes(dest))))
│││┌ @ C:\Users\wherr\.julia\packages\DataFrames\Lrd7K\src\other\broadcasting.jl:210 df[DataFrames.:!, lazydf.col] = col
││││┌ @ C:\Users\wherr\.julia\packages\DataFrames\Lrd7K\src\dataframe\dataframe.jl:669 DataFrames.insert_single_column!(df, v, col_ind)
│││││┌ @ C:\Users\wherr\.julia\packages\DataFrames\Lrd7K\src\dataframe\dataframe.jl:653 DataFrames._drop_all_nonnote_metadata!(df)
││││││┌ @ C:\Users\wherr\.julia\packages\DataFrames\Lrd7K\src\other\metadata.jl:759 DataFrames._drop_table_nonnote_metadata!(df)
│││││││┌ @ C:\Users\wherr\.julia\packages\DataFrames\Lrd7K\src\other\metadata.jl:752  = iterate(metadatakeys(df), getfield(_3, 2))
││││││││┌ @ tuple.jl:68 t[i]
│││││││││┌ @ tuple.jl:29 Base.getfield(t, i, $(Expr(:boundscheck)))
││││││││││ invalid builtin function call
│││││││││└───────────────

I think you may want to report a bug in DataFrames 1.4.1, perhaps in src\other\broadcasting.jl, that may not be in v1.3.6. Your code reported a possible bug in a different line of code, so it may not be at either of the locations reported.