Deprecation warning doesn't show line number

[davidanthoff]

I have an existing project, and when I run it on julia 0.4 RC4 I just get lots and lots of

WARNING: Base.String is deprecated, use AbstractString instead.

messages with no indication where that is occurring. Very difficult to find the real culprit in that case.

I did dig a lot now, and here is the minimal repo case:

1. Install the Mimi package Pkg.add("Mimi")
2. Use it using Mimi

Now, I will obviously fix this in Mimi, but the complete lack of line numbers in the deprecation warning here is not ideal.

This is on RC4, versioninfo():

Julia Version 0.4.0-rc4
Commit e9c9c92* (2015-10-04 03:14 UTC)
Platform Info:
  System: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

[pao]

cf #13424 (comment)

[davidanthoff]

Here is another example: I'm trying to fix these deprecation warnings for ExcelReaders.jl. I have removed all use of pure String on master, but when I run the test suite, I still get the warning that Base.String is deprecated, without any hint where it is still being used. I don't even know whether that is happening in ExcelReaders, or some package I'm using or somewhere else entirely. I tried to debug this with println statements, but couldn't find the culprit.

[davidanthoff]

I think there might be a real bug hidden in this as well, not just an inconvenience.

When I checkout the errordiag branch from the ExcelReaders package, and then run the test suite, I get this output:

julia> Pkg.test("ExcelReaders")
INFO: Testing ExcelReaders
file is of type ExcelReaders.ExcelFile
filename is of type ASCIIString
STEP 1
WARNING: Base.String is deprecated, use AbstractString instead.
WARNING: Base.String is deprecated, use AbstractString instead.
WARNING: Base.String is deprecated, use AbstractString instead.
STEP 2
STEP 2
INFO: ExcelReaders tests passed

The relevant code that prints the diagnostic info is this:

println("file is of type $(typeof(file))")
println("filename is of type $(typeof(filename))")
println("STEP 1")
for f in [file, filename]
    println("STEP 2")

So somehow the for loop line here seems to trigger the deprecation warning, which makes no sense to me.

Am I missing something very obvious here, or is there some real bug hidden here somewhere?

But in any case, this whole situation makes it almost impossible to fix these deprecation warnings, since one hardly stands a chance to find the root cause.

@StefanKarpinski Can we add this to the 0.4.0 milestone for now? I think this should be at least investigated/decided before a 0.4 is released.

[mdcfrancis]

A quick hack ( which doesn't get you the line number but does get you the Julia source file )

function Core.include(fname::ByteString)
  println( "Loading $fname")
  ccall(:jl_load_, Any, (Any,), fname)
end

Then when you do using Module you will see the files as they are loaded. You probably want to run the using once to setup the precompiled code code first then exit and do this.

[davidanthoff]

@mdcfrancis When I execute your code on the REPL as written I get

WARNING: Method definition include(Union{UTF8String, ASCIIString}) in module Core at boot.jl:261 overwritten in module Main at none:2.

I also tried it without the type annotation for fname. In both cases there is no extra output at all.

But then, ExcelReaders is just one file, so I'm not sure this is the right strategy.

[mdcfrancis]

Yes that's correct - this is 'Monkey patching' the routine which julia uses for loading data - you will see no output for modules which are pre-compiled.

But for example I get the following with Logging

julia> using Logging
Loading /home/michael/.julia/v0.4/Logging/src/Logging.jl
WARNING: Base.String is deprecated, use AbstractString instead.
WARNING: Base.String is deprecated, use AbstractString instead.
WARNING: Base.String is deprecated, use AbstractString instead.
WARNING: Base.String is deprecated, use AbstractString instead.
WARNING: Base.String is deprecated, use AbstractString instead.
WARNING: Base.String is deprecated, use AbstractString instead.

[davidanthoff]

I deleted the lib folder, but then I get pages and pages of these warnings from all sorts of packages, that also really doesn't help to narrow it down.

This seems like an issue that a lot of package devs will run into, and probably a better way around this is to just make this warning spit out a filename and a line number, right?

[mdcfrancis]

100% agree, especially given that so many packages have not been updated. What you will find though is that once you have the file with the depricated it is quick to find the line with a grep. So in the example above sll those warnings come from the one file, in the multiple file case the warnings will be located with each file.

[jiahao]

Try julia --depwarn=error on 0.4. It will turn deprecation warnings into errors, which will produce a backtrace on the first such error.

[davidanthoff]

@jiahao that sounds good, but also does nothing on my machine. Still same warnings, no errors thrown.

[ihnorton]

Windows?
On Oct 5, 2015 6:15 PM, "David Anthoff" [email protected] wrote:

@jiahao https://github.com/jiahao that sounds good, but also does
nothing on my machine. Still same warnings, no errors thrown.

—
Reply to this email directly or view it on GitHub
#13457 (comment).

[davidanthoff]

@ihnorton Yes, I posted the full versioninfo() output above.

[milktrader]

By looking at a recent travis log it appears that many of these AbstractString errors are coming from the DataArrays package so maybe do a PR to get that fixed?

I noticed quite a few from src/operators.jl in the DataArrays package.

[jiahao]

Hmmm on master/OSX using ExcelReaders produces many deprecation warnings when precompiling DataArrays, but running julia --depwarn=error doesn't throw an error in the precompilation. @vtjnash any ideas?

[ihnorton]

@davidanthoff I made you a list using #13462 😄

https://gist.github.com/ihnorton/3a9ff6bf210028264532

[ihnorton]

Fixed by #13462.

[davidanthoff]

Thanks!