Julia: `using A.B` and `using A: B` deprecations don't provide line info

Created on 4 Jan 2018  Â·  5Comments  Â·  Source: JuliaLang/julia

┌ 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.

deprecation logging

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 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!

All 5 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

StefanKarpinski picture StefanKarpinski  Â·  3Comments

yurivish picture yurivish  Â·  3Comments

omus picture omus  Â·  3Comments

omus picture omus  Â·  3Comments

StefanKarpinski picture StefanKarpinski  Â·  3Comments