coverage: support output in LCOV tracefile format

[vtjnash]

Since Base code-coverage has been broken for stdlibs for a long time, this adds support for a format that doesn't share the same problems. This'll also allow us to adopt the newly-added code-caches for coverage, and to add handling of them to Coverage.jl similar to that already present in Revise.jl.

[staticfloat]

Adding a test and removing the unnecessary comments would make this good to go from my perspective. I'm just kind of assuming that the info it generates is good; I haven't run it locally to check it, which is why I'm particularly interested in a test.

[vtjnash]

OK, I added a small test so we'll be alerted earlier if coverage output changes. I had tested the results locally with genhtml to see that it looked valid, and more recently now have also checked that my PRs to Coverage.jl and CoverageBase.jl are successful at analyzing a sample file.

[JeffBezanson]

Why is this on the milestone? It adds a new command line option, which is a new feature.

[JeffBezanson]

Rebased as #30453 for release-1.1.

[bramtayl]

a) Where is the documentation about how to use this?

b) I've been doing some investigating into why code coverage for LightQuery seems low despite the recent improvements. I tried running the command

julia --code-coverage=tracefile-%p.info --code-coverage=user -e 'include("runtests.jl")'

This gives me a 'tracefile-DIGITS.info' file in my test directory. I can view this info in Atom using the lcov-info package (LCOV itself doesn't seem to support windows...), but first I have to make a coverage directory and rename the file to lcov.info. There's definitely something wrong. I'm getting this entry

SF:ia\dev\LightQuery\src\macros.jl
DA:58,12454531
DA:83,3405931
LH:2
LF:2
end_of_record

I just want a green coverage badge halp

BTW Version 1.2.0-DEV.307 (2019-02-11)

[bramtayl]

Line 58 points to this macro:

macro _(body)
    anonymous(LineNumberNode(@__LINE__, @__FILE__), macroexpand(@__MODULE__, body)) |> esc
end

[bramtayl]

Aha! the SF:/ia this is fixed if I put Symbol around @__FILE__; apparently LineNumberNode expects one. still, some docs would be nice.

[bramtayl]

Also, looking at this, I'm noticing @__LINE__ doesn't seem to do what I'd hope it would do: point to the line number where the macro was called, not defined. I suppose there's no way to get that?

[bramtayl]

Turns out I just need to pass __source__. Nice.