┌ Warning: `using A: B` will only be allowed for single bindings, not modules. Use `using A.B` instead
│ caller = ip:0x0
â”” @ Core :-1
This doesn't tell you anything about where the code that generated the warning lives. It may be fairly nontrivial to add this though. I don't pretend to know how much of the C internals work, but this warning comes from jl_depwarn in src/toplevel.c, and I'm not sure how one would pass line info to jl_depwarn.
Any chance you can test whether #20641 helps? EDIT: nvm, I see there's a merge conflict. Let me see what I can do.
The issue here is that depwarn (on the julia side) assumes the offending code is a julia function which called the deprecated function. This isn't true in various circumstances within the C code, but not all calls to jl_depwarn keep this in mind. As a general solution, we need to look at each place jl_depwarn is called and determine whether looking up the stack is the right thing to do.
In this particular case the warning is emitted from jl_toplevel_eval_flex which looks like it's acting as an interpreter for a very limited set of ASTs involving import/using, so the offending file and line must be looked up in the interpreter state rather than an actual stack frame. I believe this would work ok if we were inside the interpreter proper due to a lot of recent work by @Keno, but jl_toplevel_eval_flex looks like it's not counted as part of the interpreter at the moment.
A direct way to fix this problem is to just have an alternative to jl_depwarn where we pass the file and line number information explicitly. In this particular case reading the globals jl_filename and jl_lineno would probably work most of the time because we're likely to be we are evaluating a top level expression (though what about eval?). Unfortunately using these globals is pretty fraught in general and can give completely irrelevant results in many cases!
Hello,
instead of opening a new issue I would like to comment here that the converse
┌ Warning: `using A.B` will only be allowed for modules, not single bindings. Use `using A: B` instead
│ caller = ip:0x0
â”” @ Core :-1
is just as bad.
Best Regards
Christof
Note that if you start julia like julia --depwarn=error, then you actually see full, proper backtraces on deprecation warnings (like this example). That's what I usually do when I'm in "hunt deprecations down" mode; you just keep trying to load a package and fixing the deprecations until it finally loads.
Not relevant to 1.0+, unlikely to be fixed and backported to 0.7.
Most helpful comment
The issue here is that
depwarn(on the julia side) assumes the offending code is a julia function which called the deprecated function. This isn't true in various circumstances within the C code, but not all calls tojl_depwarnkeep this in mind. As a general solution, we need to look at each placejl_depwarnis called and determine whether looking up the stack is the right thing to do.In this particular case the warning is emitted from
jl_toplevel_eval_flexwhich looks like it's acting as an interpreter for a very limited set of ASTs involving import/using, so the offending file and line must be looked up in the interpreter state rather than an actual stack frame. I believe this would work ok if we were inside the interpreter proper due to a lot of recent work by @Keno, butjl_toplevel_eval_flexlooks like it's not counted as part of the interpreter at the moment.A direct way to fix this problem is to just have an alternative to
jl_depwarnwhere we pass the file and line number information explicitly. In this particular case reading the globalsjl_filenameandjl_linenowould probably work most of the time becausewe're likely to bewe are evaluating a top level expression (though what abouteval?). Unfortunately using these globals is pretty fraught in general and can give completely irrelevant results in many cases!