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
Comments
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. |
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. |
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. |
Cool idea. Like everything in Base, or other user supplied modules. |
All I get seem to be tons of warnings about lines in Example:
Edit: With the latest master version of the package, the
|
I get similar dynamic dispatch and Union warnings form tuple.jl and bitarray.jl. |
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. |
Thanks for the quick fix! |
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...
The text was updated successfully, but these errors were encountered: