ypconstante

ypconstante

How to enable the native code coverage from OTP 27?

I’m trying to enable the native coverage from OTP 27, but so far nothing has worked.

I’ve added erlc_options: [:debug_info, :line_coverage, {:line_coverage, true}] to the project config and set the environment variable ERL_AFLAGS="+JPcover true", but it didn’t do anything.

I added these lines to a test to see what is happening:

      dbg :code.coverage_support() # true
      dbg :code.get_coverage_mode() # :line_counters
      dbg :code.get_coverage_mode(mod) # :none

All project modules have :none as the coverage mode, only if I run with :cover that it changes to :line_counters.

Is there a way to have coverage without :cover compiling the modules? Locally :cover compile takes 7 seconds, so I’m trying to find a way to speed it up, or to have coverage without using it.

First 7 of 7 Posts! Switch mode

D4no0

D4no0

Doesn’t the compilation get cached?

ypconstante

ypconstante

It doesn’t, after running time mix test some_test_file.exs --cover multiple times,

Test output:

Finished in 0.1 seconds (0.1s async, 0.00s sync)
22 tests, 0 failures

Time output:

mix test some_test_file.exs --cover  58.22s user 12.81s system 449% cpu 15.812 total

:cover compiling takes 7 seconds, and then the rest of the time is spent on creating the summary and HTML generation. On CI --cover adds a whole minute, which is the main reason I wanted to enable this native coverage.

ypconstante

ypconstante

I did make some progress, but still didn’t manage to make it work

Environment variables

export ERL_COMPILER_OPTIONS="[line_coverage,force_line_counters]"
export ELIXIR_ERL_OPTIONS="+JPcover line_counters"
    dbg :code.coverage_support() # true
    dbg :code.get_coverage_mode() # :line_counters
    dbg :code.get_coverage_mode(mod) # :line_counters
    dbg mod.module_info()[:compile][:options] # [:no_spawn_compiler_process, :from_core, :no_core_prepare, :no_auto_import, :line_coverage, :force_line_counters]
    dbg :code.get_coverage(:line, mod)  # []

:code.get_coverage is returning an empty list, but if I init :cover it returns the expected data.

josevalim

josevalim

Creator of Elixir

I believe cover will use native coverage by default. The native coverage speeds up the time for running tests, it may not necessarily speed up the time for compiling nor building the reports.

bjorng

bjorng

Erlang Core Team

Do you see any executable_line instructions if you disassemble the compiled module?

This should be the way to do it from Elixir:

:beam_disasm.file(mod)

Here is an extract from a disassembly of one of my Erlang modules:

     [{function,t,1,2,
                      [{label,1},
                       {line,1},
                       {func_info,{atom,t},{atom,t},1},
                       {label,2},
                       {executable_line,2,1},
                       {executable_line,3,4},
                       {call_only,1,{t,'-t/1-lc$^0/1-0-',1}}]},

Yes, cover uses native coverage on systems that support it.

ypconstante

ypconstante

:beam_disasm.file(:code.which(mod)) doesn’t have executable_line instructions, is there any other configuration that I need to add to add them?

bjorng

bjorng

Erlang Core Team

No, that’s correct. That will tell the Erlang compiler to instrument the code. However, it seems that the way the Elixir compiler invokes the Erlang compiler, line_coverage instrumentation will not work for Elixir code.

To confirm, I changed your setup to:

export ERL_COMPILER_OPTIONS=[line_coverage,force_line_counters,time]

That will instruct the Erlang compiler to print the name of each pass it executes.

If I then compile an Erlang module, the first few passes will be shown as follows:

Eshell V15.2.4 (press Ctrl+G to abort, type help(). for help)
1> c(t).
Compiling t.erl
 remove_file                   :      0.000 s       0.9 kB
 parse_module                  :      0.006 s       2.5 kB
 transform_module              :      0.000 s       2.5 kB
 lint_module                   :      0.005 s       2.5 kB
 beam_docs                     :      0.002 s       2.5 kB
 remove_doc_attributes         :      0.000 s       2.5 kB
 compile_directives            :      0.000 s       2.5 kB
 sys_coverage                  :      0.001 s       2.8 kB
 expand_records                :      0.002 s       2.8 kB
 core                          :      0.007 s      20.9 kB
 sys_core_fold                 :      0.003 s      14.7 kB
 sys_core_alias                :      0.001 s      14.7 kB

The sys_coverage pass is the pass that adds the executable_line instructions.

If I compile using the Elixir compiler, the sys_coverage pass is not run:

ex(1)> c "test.ex"
Compiling /Users/bjorng/git/otp/test.ex
 get_module_name_from_core     :      0.000 s      25.5 kB
 core_lint_module              :      0.000 s      25.8 kB
 sys_core_fold                 :      0.000 s      20.9 kB
 sys_core_alias                :      0.000 s      20.9 kB
 core_transforms               :      0.000 s      20.9 kB

That’s why there are no executable_line instructions in the generated BEAM code.

Where Next?

Trending in Questions Top

jonnycharles
I’m in search of an Elixir library that offers PDF generation capabilities similar to Ruby’s Prawn. While there have been discussions abo...
New
spammy
I’m looking to build a personal workflow to quickly deploy web applications written in elixir/phoenix, for local consumption (ie not on t...
New
silverdr
Using Phoenix.LiveView.TagEngine as an EEx.Engine is deprecated! To compile HEEx, use Phoenix.LiveView.TagEngine.compile/2 instead. Sta...
New
saveman71
Hello ! We want new/edit form pages to POST/PUT to their own URL rather than the resources REST defaults (post /things, put /things/:id)...
New
dli
Before I dive in myself, did anyone successfully sprinkle Hologram into their existing LiveView app? Looking for hints regarding: Addi...
New
bottlenecked
Hi all, I wanted to ask how the community is dealing with post-release steps. Today we have Ecto migrations, which make sure that the db...
New
michallepicki
I am using Oban and occasionally, shortly after a deployment, a handful of jobs can fail because of dependency on other parts of the syst...
New

Other Trending Topics Top

JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve. They are GUI (Emerge) and State management (S...
New
ausimian
Emily is an Elixir library that runs Nx computations on Apple’s MLX. Install it as the default Nx backend and Nx, defn, Axon, Nx.Serving,...
New
type1fool
I just stumbled on a newly redesigned elixir-lang.org. :tada: It looks like @Software_Mansion did the work, and I think it is generally a...
New
akoutmos
@hugobarauna and I (Alex Koutmos) have been hard at work on writing a book on Nerves that takes you from simply blinking LEDs to building...
New

We're in Beta

About us Mission Statement