cover aggregation bug

[MarkoMin]

Describe the bug
Description is here, I thought that the bug is in rebar3, but it probably isn't.

To Reproduce
I'm not aware what the actual trigger is, but project that is tested with both proper and ct should exploit the behavior. Coverage for proper and ct independently both look correct! Minimal reproduce is in archive file (notice how line that is considered ignored in independent cases is considered unused in aggregated coverage). To reproduce, run rebar3 ct --cover, rebar3 eunit --cover, rebar3 proper --cover and finally rebar3 cover to look at the results.

Expected behavior

Aggregated coverage should be greater than independent coverages and ignored lines shouldn't be counted as unused

Affected versions
OTP 26.1.2

Additional context
coverage_repro.tar.gz

[bjorng]

Thanks for the bug report. This bug will get fixed sooner if you could further minimize how to reproduce it.

[MarkoMin]

Okay, so the issue is that cover data is collected on different files. The issue is not related to cover aggregation, or any particular test utility, but to the way cover works.

Minimal reproduce (using already provided example):

1. rebar3 ct --cover
2. rebar3 proper --cover
3. rebar3 cover
4. Modify a.erl by inserting a few comments
5. rebar3 cover

After those steps, proper and ct cover data is not updated and is referring to old line numbers, resulting in false positives ad false negatives. This actually is user's (my) fault, but would it make sense to invalidate cover data if the file is changed? cover is using old cover data on modified files.

Is there any metadata in cover data that we could use for verifying that file was not modified?