From: mame@... Date: 2016-03-31T17:49:20+00:00 Subject: [ruby-core:74750] [Ruby trunk Bug#12220] Why does Coverage keep previously-loaded files as empty arrays? Issue #12220 has been updated by Yusuke Endoh. I'm unsure what behavior you expect. Do you mean that it should pass the following two tests? ~~~~ Coverage.start require tmp + '/test.rb' Coverage.result Coverage.start assert_equal {}, Coverage.result ~~~~ ~~~~ Coverage.start require tmp + '/test.rb' Coverage.result Coverage.start coverage_test_method assert_equal 1, Coverage.result.size # what should Coverage.result return precisely? ~~~~ ---------------------------------------- Bug #12220: Why does Coverage keep previously-loaded files as empty arrays? https://bugs.ruby-lang.org/issues/12220#change-57883 * 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: