[#116016] [Ruby master Bug#20150] Memory leak in grapheme clusters — "peterzhu2118 (Peter Zhu) via ruby-core" <ruby-core@...>
Issue #20150 has been reported by peterzhu2118 (Peter Zhu).
7 messages
2024/01/04
[#116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>
Issue #20205 has been reported by byroot (Jean Boussier).
77 messages
2024/01/23
[ruby-core:116219] [Ruby master Bug#19857] Eval coverage is reset after each `eval`.
From:
"mame (Yusuke Endoh) via ruby-core" <ruby-core@...>
Date:
2024-01-16 07:47:38 UTC
List:
ruby-core #116219
Issue #19857 has been updated by mame (Yusuke Endoh).
Status changed from Open to Rejected
Sorry, but I am not keen on this proposal. Let me reject this once.
When I started developing the covearge library, I decided that its target is "source files that actually exist".
The measured coverage is visually observed by a human, which requires source code, and Ruby interpreter did not keep the eval'ed source code (at that time). I think that the design decision to target only source files was natural.
Because the Rails view code (.erb) exists as a file, I thought that it is the target of covearge library. So I accepted #19008.
Beyond that, measuring coverage on dynamically generated code conflicts with the coverage library's initial design decision.
To be honest, I don't want to further complicate the coverage library. Frankly, its API is already very complicated. I no longer want to expand it beyond the initial design decision.
---
One constructive note.
When I first started implementing the coverage library, I had no choice but to implement it as a built-in, but now we have TracePoint, which is well-designed and general-purpose than the coverage library.
Also, Prism API is being developed, and it may be possible (although I think TracePoint needs to be extended) to radically improve the coverage measurement on a column-by-column basis rather than line-by-line basis.
I don't have time right now, but I would like to rebuild the library as a pure external gem in future, i.e. `coverage2` or something, with dynamically generated code, etc. in mind from the beginning.
----------------------------------------
Bug #19857: Eval coverage is reset after each `eval`.
https://bugs.ruby-lang.org/issues/19857#change-106238
* Author: ioquatix (Samuel Williams)
* Status: Rejected
* Priority: Normal
* Assignee: ioquatix (Samuel Williams)
* Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED
----------------------------------------
It seems like `eval` based coverage is reset every time eval is invoked.
```ruby
#!/usr/bin/env ruby
require 'coverage'
def measure(flag)
c = Class.new
c.class_eval(<<~RUBY, "foo.rb", 1)
def foo(flag)
if flag
puts "foo"
else
puts "bar"
end
end
RUBY
return c.new.foo(flag)
end
Coverage.start(lines: true, eval: true)
# Depending on the order of these two operations, different coverage is calculated, because the evaluation of the code is considered different, even if the content/path is the same.
measure(false)
measure(true)
p Coverage.result
```
Further investigation is required.
--
https://bugs.ruby-lang.org/
______________________________________________
ruby-core mailing list -- ruby-core@ml.ruby-lang.org
To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/