From: "jeremyevans0 (Jeremy Evans)" Date: 2022-09-22T21:50:18+00:00 Subject: [ruby-core:110006] [Ruby master Feature#19008] Introduce coverage support for `eval`. Issue #19008 has been updated by jeremyevans0 (Jeremy Evans). ioquatix (Samuel Williams) wrote in #note-8: > > I would prefer 3. > > @jeremyevans0 what's the use-case for your proposal, because it would be much harder to digest with the coverage tool. As it stands, with this PR, I can swap out my own coverage implementation and everything just works. But with your proposal, it won't work. By the way, if you wanted 3 separate coverage entries, you can do this: > > ```ruby > 3.times do |i| > eval <<-END, binding, __FILE__ + ":#{i}", __LINE__+1 > case i > when 0 > p "a" > when 1 > p "2" > else > p "b" > end > END > end > ``` > > > I think we need an option to disable it if it is enabled by default. > > Can you explain the use case? In what situations will it be a problem? I'm not against introducing a keyword, but I want to know what problem it addresses, because in my case such a usage is not desirable. Your use case (ERB coverage) is apparently limited to files that aren't required. However, `eval` methods are used with `__FILE__` on a regular basis for metaprogramming. In many cases, I don't care about `eval`ed code, and it would be nice to be able to turn off coverage in such cases, instead of having to filter coverage results to specifically exclude them. There should be an easy way to get backwards compatibility with Ruby 3.1 and earlier versions, which is what a keyword would enable. In the cases where I do care and I want to check coverage of `eval`ed code, it would be best to be able to look at all `eval`s separately. It looks like your current approach is to just override any existing coverage entry for each new `eval`, which does not allow for that. Your recommendation to modify the third argument to `eval` breaks various things, such as `__FILE__` inside the evaled code, and changing backtrace lines. It's likely a keyword argument approach to `Coverage.start` would allow for more configurable behavior. Maybe an callable keyword that is passed the file and line of the eval, and returns the coverage key to use (and have `nil` not record coverage)? ---------------------------------------- Feature #19008: Introduce coverage support for `eval`. https://bugs.ruby-lang.org/issues/19008#change-99257 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- I'd like to introduce coverage support for `eval`. I mostly only care about the case where an explicit path is given, and I'd even be okay to only handle the case where the line number is the default (0). https://github.com/ruby/ruby/pull/6396 This is an incredibly useful feature for computing coverage of ERB templates and other similar things. -- https://bugs.ruby-lang.org/ Unsubscribe: