ypconstante

ypconstante

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.

Showing Posts 1 to 7

D4no0

D4no0

Doesn’t the compilation get cached?

ypconstante

ypconstante OP

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 OP

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 OP

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

— All posts loaded —

Where Next? Top

Trending in Questions Top

Blokh
Hey guys, I’ve got a huge CSV ( around 10 GB ) that needs to be processed hourly Do you guys have any suggestions what is the best prac...
New
kszambelanczyk
Hello! Could someone please give me a help/sample code, how to delete a file from s3 using waffle/waffle_ecto from Phoenix app. I creat...
New
RemyXRenard
I’m seeing that a list inside a Kino.DataTable will be interpreted as a charlist, even if the Kino.configure() is set to charlists: :as_l...
New
matt-savvy
Anyone here using Honeybadger? My Honeybadger account is being overwhelmed with noise from some bots. Seeing a lot of Bandit.HTTPError...
New
velrest
So my question is quite simple and i have found no conclusive answer on forum, google or AI. Should we use :erlang.float for Integer to ...
New
samoloth
Hi, I’ve just set up an application with ash_authentication. There is only magic link strategy for now, so there is no confirmation add o...
New
FlyingNoodle
If a change or preparation module uses Ash.Changeset.get_argument/2 or Ash.Query.get_argument/2 (or any of the other get_argument functio...
New

Other Trending Topics Top

mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
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
mcass19
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
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
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews