Bug #19715: Coverage oneshot_lines mode is not working after result clear

• Status: Rejected
• Assignee: -
• Target version: -
• Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN

[ngan (Ngan Pham)]

Given a simple Ruby file (foo.rb):

def hello
  puts "hello"
end

If I do the following in irb, I get unexpected results:

irb(main):001:0> require 'coverage'
irb(main):002:0> Coverage.setup(oneshot_lines: true)
=> nil
irb(main):003:0> require_relative 'foo'
=> true
irb(main):004:0> Coverage.resume
=> nil
irb(main):005:0> hello
hello
=> nil
irb(main):006:0> Coverage.suspend
=> nil
irb(main):007:0> Coverage.result(stop: false, clear: true)
=> {"/project/foo.rb"=>{:oneshot_lines=>[2]}}
irb(main):008:0> Coverage.resume
=> nil
irb(main):009:0> Coverage.suspend
=> nil
irb(main):010:0> Coverage.result(stop: false, clear: true)
=> {"/project/foo.rb"=>{:oneshot_lines=>[]}}
irb(main):011:0> Coverage.resume
=> nil
irb(main):012:0> hello
hello
=> nil
irb(main):013:0> Coverage.suspend
=> nil
irb(main):014:0> Coverage.result(stop: false, clear: true)
=> {"/project/foo.rb"=>{:oneshot_lines=>[]}}

You can see that in the third Coverage.result call, oneshot_lines did not populate despite me executing hello.

If I use lines, then it works the way I'd expect it to:

irb(main):001:0> require 'coverage'
irb(main):002:0> Coverage.setup(lines: true)
=> nil
irb(main):003:0> require_relative 'foo'
=> true
irb(main):004:0> Coverage.resume
=> nil
irb(main):005:0> hello
hello
=> nil
irb(main):006:0> Coverage.suspend
irb(main):007:0> Coverage.result(stop: false, clear: true)
=> {"/project/foo.rb"=>{:lines=>[0, 1, nil]}}
irb(main):008:0> Coverage.resume
=> nil
irb(main):009:0> Coverage.suspend
irb(main):010:0> Coverage.result(stop: false, clear: true)
=> {"/project/foo.rb"=>{:lines=>[0, 0, nil]}}
irb(main):011:0> Coverage.resume
=> nil
irb(main):012:0> hello
hello
=> nil
irb(main):013:0> Coverage.suspend
irb(main):014:0> Coverage.result(stop: false, clear: true)
=> {"/project/foo.rb"=>{:lines=>[0, 1, nil]}}

I get that oneshot_lines is only suppose to count the line once, but I'd expect that upon a reset/clear, it should remark the line as executed. I wasn't sure if this is expected behavior or a bug.

[mame (Yusuke Endoh)]

• Status changed from Open to Rejected

Hi @ngan (Ngan Pham)

The documentation may not be clear, but this is by design. (Document improvements are welcome!)

oneshot_lines is a mode that reports execution at most once for each line. The record is not reset even by clear: true. Currently, we do not provide a way to reset the record.

The supposed use case for oneshot_lines is to get information for removing unnecessary codes. By periodically calling Coverage.result(stop: false, clear: true) on a long-running server, you can collect code line numbers that are executed. Conversely, this information will reveal the code that is most likely no longer being used.
In this use case, if duplicate line executions are reported before and after clear: true, it will bring unneeded overhead.

Do you want such a reset feature? If so, please let me know the use case for that.

[ngan (Ngan Pham)]

mame (Yusuke Endoh) wrote in #note-1:

oneshot_lines is a mode that reports execution at most once for each line. The record is not reset even by clear: true. Currently, we do not provide a way to reset the record.

The supposed use case for oneshot_lines is to get information for removing unnecessary codes. By periodically calling Coverage.result(stop: false, clear: true) on a long-running server, you can collect code line numbers that are executed. Conversely, this information will reveal the code that is most likely no longer being used.
In this use case, if duplicate line executions are reported before and after clear: true, it will bring unneeded overhead.

Do you want such a reset feature? If so, please let me know the use case for that.

Ah yes, we were looking to use oneshot_lines to determine which tests run which production files. Using lines is slow so I figured oneshot_lines was usable for this. We do need to clear and reset the markers after each test though. I might switch to use TracePoint since the lines is really slow.