Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Depth #17

Closed
yakir12 opened this issue Oct 9, 2018 · 8 comments
Closed

Depth #17

yakir12 opened this issue Oct 9, 2018 · 8 comments
Labels
enhancement New feature or request

Comments

@yakir12
Copy link

yakir12 commented Oct 9, 2018

It would be very useful (and perhaps improve performance) if only code within the current module or some such definition would be tested and all deeper code would just be ignored... The thing is that users don't want to get warnings on things they can't do anything about, just their own code. This might be hard to implement...

@pfitzseb pfitzseb added the enhancement New feature or request label Oct 9, 2018
@MikeInnes
Copy link
Member

I don't think it'd be that hard to do, when we hit a function call just check what module the relevant method is in. I think there's also some scope for the UI side to do filtering based on current file or module, though.

@pfitzseb
Copy link
Member

pfitzseb commented Oct 9, 2018

Runtime is a concern though, so it'd be nice to be able to set a max depth or indeed only analyse functions in a specific module/file.

@MikeInnes
Copy link
Member

We could also have a set of "known good" functions or signatures that we always skip. You have to be a bit careful with that (higher order functions are always at risk for example) but profiling would probably turn up some things safe to skip.

@yakir12
Copy link
Author

yakir12 commented Oct 9, 2018

Cool idea. Like everything in Base, or other user supplied modules.

@x-ji
Copy link

x-ji commented Nov 2, 2018

All I get seem to be tons of warnings about lines in sysimg.jl, event.jl, coreio.jl, error.jl, abstractdict.jl etc. before anything about my own code even appears. Is it normal? Or do they still imply problems in my code. How may I interpret the outputs?

Example:

┌ Warning: getproperty returns Union{Int64, Ptr{Nothing}, AbstractString, Array{UInt8,1}}
└ @ sysimg.jl:18
┌ Warning: dynamic dispatch to ((Base.getfield)(itr, ondone))()
└ @ io.jl:880
┌ Warning: getproperty returns Union{Bool, IOStream, Function}
└ @ sysimg.jl:18
┌ Warning: getproperty returns Union{Int64, Ptr{Nothing}, AbstractString, Array{UInt8,1}}
└ @ sysimg.jl:18
┌ Warning: getproperty returns Union{Bool, IOStream, Function}
└ @ sysimg.jl:18
┌ Warning: getproperty returns Union{Bool, IOStream, Function}
└ @ sysimg.jl:18
┌ Warning: getproperty returns Union{Int64, Ptr{Nothing}, AbstractString, Array{UInt8,1}}
└ @ sysimg.jl:18

Edit: With the latest master version of the package, the getproperty returns Union messages are gone, though some other messages not about sysimg.jl are still there:

┌ Warning: getindex returns Union{Char, String}
└ @ tuple.jl:24
Reading training corpus┌ Warning: uses global variable Base.uv_jl_writecb_task
└ @ stream.jl:810
┌ Warning: get returns Any
└ @ abstractdict.jl:597
┌ Warning: uses global variable Base.uv_eventloop
└ @ libuv.jl:89
┌ Warning: dynamic dispatch to (Base.rethrow)($(Expr(:the_exception)))
└ @ event.jl:190
┌ Warning: Base.try_yieldto returns Any
└ @ event.jl:186
┌ Warning: reftask is assigned as Union{Nothing, RefValue{Task}}
└ @ event.jl:253
┌ Warning: wait returns Any
└ @ event.jl:244
┌ Warning: get returns Any
└ @ abstractdict.jl:597
┌ Warning: getindex returns Any
└ @ abstractdict.jl:601
┌ Warning: pop! returns Any
└ @ abstractdict.jl:607
┌ Warning: pop! returns Any
└ @ abstractdict.jl:619
┌ Warning: buf is assigned as Union{Nothing, GenericIOBuffer{Array{UInt8,1}}}
└ @ stream.jl:837
┌ Warning: dynamic dispatch to (Base.bytesavailable)((Base.getfield)(s, sendbuf))
└ @ stream.jl:838
┌ Warning: dynamic dispatch to (Base.unsafe_write)((Base.getfield)(s, sendbuf), p, n)
└ @ stream.jl:840
┌ Warning: dynamic dispatch to (Base.unsafe_write)((Base.getfield)(s, sendbuf), p, n)
└ @ stream.jl:846

┌ Warning: buf is assigned as Union{Nothing, GenericIOBuffer{Array{UInt8,1}}}
└ @ stream.jl:870
┌ Warning: dynamic dispatch to (getfield(Base, Symbol("#kw##schedule"))())(%new(NamedTuple{(:error,),Tuple{Bool}}, error), Base.schedule, φ (%19 => %15, %141 => %136), arg)
└ @ event.jl:68
┌ Warning: dynamic dispatch to (Base.schedule)(φ (%19 => %15, %141 => %136), arg)
└ @ event.jl:68
┌ Warning: dynamic dispatch to (getfield(Base, Symbol("#kw##schedule"))())(%new(NamedTuple{(:error,),Tuple{Bool}}, error), Base.schedule, (Base.arrayref)(true, (Base.getfield)(c, waitq), 1),arg)
└ @ event.jl:74
┌ Warning: dynamic dispatch to (Base.schedule)((Base.arrayref)(true, (Base.getfield)(c, waitq), 1), arg)
└ @ event.jl:74
┌ Warning: x is assigned as Union{Char, String}
└ @ strings/io.jl:41
┌ Warning: uses global variable Base.stdout
└ @ coreio.jl:4
┌ Warning: dynamic dispatch to (Base.println)(π (Base.stdout, IO), (getfield)(xs, 1))
└ @ coreio.jl:4
┌ Warning: dynamic dispatch to (Base.getproperty)(Base.Main, Base)
└ @ error.jl:106
┌ Warning: dynamic dispatch to (Base.getproperty)((Base.getproperty)(Base.Main, Base), SystemError)
└ @ error.jl:106
┌ Warning: dynamic dispatch to ((Base.getproperty)((Base.getproperty)(Base.Main, Base), SystemError))(p, $(Expr(:foreigncall, :jl_errno, Int32, svec(), :ccall, 0)), extrainfo)
└ @ error.jl:106
┌ Warning: dynamic dispatch to ((Base.getfield)(itr, ondone))()
└ @ io.jl:880

@kurbkid
Copy link

kurbkid commented Jan 23, 2019

I get similar dynamic dispatch and Union warnings form tuple.jl and bitarray.jl.
Does this mean that a lot of base functions are not adhering to the highest quality standards?
Or that I am using the functions wrong?

@mkborregaard
Copy link

I get warnings galore from dict.jl, iterators.jl and tuple.jl as well - limiting depth to the present module (or a list of modules for org packages; or just anything non-Base) would be great.

@mkborregaard
Copy link

Thanks for the quick fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants