If a module includes eunit.hrl, a parse transform adds the function test/0 on line 0 in the module. A bug in OTP-18.0 caused cover:analyse_to_file/1 to fail to insert cover data in the output file when line 0 existed in the cover data table. The bug is corrected by the commit "Fix cover output file". This commit adds a test which checks that the bug is not introduced again.
It is possible that not just the source but even the beam of a module is not available when calling analyse_to_file. For example when coverdata is imported from an old file and since then a module was removed. Before this fix cover:analyse_to_file/3 could possibly never return because of a helper process crashed with error:undef and never reply to the caller. At the same time link the helper process to cover_server so any further error won't let the caller waiting indefinitely.
Add functions for cover compilation and analysis on multiple files. This allows for more parallelisation. All functions for cover compilation can now take a list of modules/files. cover:analyse/analyze and cover:analyse_to_file/analyze_to_file can be called without the Modules arguement in order to analyse all cover compiled and imported modules, or with a list of modules. Also, the number of lookups in ets tables is reduced, which has also improved the performance when analysing and resetting cover data.
OTP-8188 introduced a fix for handling last expressions in expressions like case, try and friends. However the fix did not account that some of those expressions like receive may have no clauses (only an after clause), leading to a function clause error when cover compiling code with such expressions.
Replace the 'erlang:binary_to_term/1' and 'erlang:binary_to_term/2' Erlang wrappers taking care of failure after yield with management of this in the hidden yield BIF.
The reconnect/1 test starts another node and takes down the connection to it for a while. However, it has been in observed in our daily builds that sometimes a "spontaneous" re-connection occurs. I think that it because of the call to rpc:cast/3 which internally will set the group leader for the remote process to a process on the test_server node. It seems that sometimes the group_leader/2 call will re-establish the connection. Unfortunately, I have not been able to force this to happen by inserting delays in the rpc module, so it it still just an hypothesis. However, letting the other node do the disconnection does seem to fix the problem and intuitively that should be safer way to do it because the group_leader/2 call and the disconnection will be executed sequentially on the same node instead of concurrently from two different nodes.