From: mame@... Date: 2016-03-31T17:14:18+00:00 Subject: [ruby-core:74747] [Ruby trunk Bug#12220] Why does Coverage keep previously-loaded files as empty arrays? Issue #12220 has been updated by Yusuke Endoh. Benoit Daloze wrote: > Tsuyoshi Sawada wrote: > > So, was it or was it not a bug that it returns empty arrays? > > I consider it a bug in that it seems to be unintentional and it is just a side-effect of the implementation to disable coverage when reset. It was actually intentional. Please read the test case of #4796. ~~~~ Coverage.start require tmp + '/test.rb' Coverage.result Coverage.start coverage_test_method assert_equal 1, Coverage.result.size # <=== HERE ~~~~ It explicitly requires the second call of `Coverage.result` return non-empty hash after restarted. I cannot remember the rationale precisely, but I think keeping the filename was critical, at least, for his use case. So, returning an empty Hash breaks the compatibility. I think of some possibilities to make it "intuitive" with keeping the test case. One is your patch. I think it is the same behavior as my first implementation. But I'm afraid if it breaks compatibility. Another is clearing all counters (to 0) instead of clearing the array itself, as Tsuyoshi Sawada and #9572 proposed. I don't really like this because I expect the same code to be excluded again after restarted. But if I have to do something, this seems the most reasonable choice. Anyway, I feel defensive to change the API even if it is a little awkward, unless there is actual use case. Thank you, ---------------------------------------- Bug #12220: Why does Coverage keep previously-loaded files as empty arrays? https://bugs.ruby-lang.org/issues/12220#change-57880 * Author: Benoit Daloze * Status: Open * Priority: Normal * Assignee: Yusuke Endoh * ruby -v: ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux] * Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN ---------------------------------------- For instance, ruby -e 'require "coverage"; Coverage.start; require "set"; Coverage.result; Coverage.start; require "tmpdir"; p Coverage.result' {".../lib/ruby/2.2.0/set.rb"=>[], ".../lib/ruby/2.2.0/tmpdir.rb"=>[nil, nil, nil, nil, nil, nil, 1, 1, ...]} So Coverage.result stops coverage but also does some cleaning up. I think the most intuitive would be that the coverage Hash would be reset to be empty, but instead it's filled with empty arrays. As an example, this makes it fairly awkward to test and it enforces irreversible global state (https://github.com/ruby/spec/pull/219). I also do not see how this would be useful for coverage libraries. Is there a reason for this behavior? If not, would it be OK to clear the Hash when calling #result? ---Files-------------------------------- 0001-ext-coverage-coverage.c-Fully-reset-coverage-to-not-.patch (5.14 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: