[#109844] [Ruby master Feature#18996] Proposal: Introduce new APIs to reline for changing dialog UI colours — "st0012 (Stan Lo)" <noreply@...>

Issue #18996 has been reported by st0012 (Stan Lo).

14 messages 2022/09/07

[#109850] [Ruby master Feature#19000] Data: Add "Copy with changes method" [Follow-on to #16122 Data: simple immutable value object] — "RubyBugs (A Nonymous)" <noreply@...>

Issue #19000 has been reported by RubyBugs (A Nonymous).

42 messages 2022/09/08

[#109905] [Ruby master Bug#19005] Ruby interpreter compiled XCode 14 cannot build some native gems on macOS — "stanhu (Stan Hu)" <noreply@...>

Issue #19005 has been reported by stanhu (Stan Hu).

28 messages 2022/09/15

[#109930] [Ruby master Bug#19007] Unicode tables differences from Unicode.org 14.0 data and removed properties since 13.0 — "nobu (Nobuyoshi Nakada)" <noreply@...>

Issue #19007 has been reported by nobu (Nobuyoshi Nakada).

8 messages 2022/09/17

[#109937] [Ruby master Feature#19008] Introduce coverage support for `eval`. — "ioquatix (Samuel Williams)" <noreply@...>

Issue #19008 has been reported by ioquatix (Samuel Williams).

23 messages 2022/09/17

[#109961] [Ruby master Bug#19012] BasicSocket#recv* methods return an empty packet instead of nil on closed connections — "byroot (Jean Boussier)" <noreply@...>

Issue #19012 has been reported by byroot (Jean Boussier).

8 messages 2022/09/20

[#109985] [Ruby master Feature#19015] Language extension by a heredoc — "ko1 (Koichi Sasada)" <noreply@...>

Issue #19015 has been reported by ko1 (Koichi Sasada).

14 messages 2022/09/22

[#109995] [Ruby master Bug#19016] syntax_suggest is not working with Ruby 3.2.0-preview2 — "hsbt (Hiroshi SHIBATA)" <noreply@...>

Issue #19016 has been reported by hsbt (Hiroshi SHIBATA).

9 messages 2022/09/22

[#110097] [Ruby master Feature#19024] Proposal: Import Modules — "shioyama (Chris Salzberg)" <noreply@...>

SXNzdWUgIzE5MDI0IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IHNoaW95YW1hIChDaHJpcyBTYWx6YmVy

27 messages 2022/09/27

[#110119] [Ruby master Bug#19026] Add `Coverage.supported?(x)` to detect support for `eval` coverage flag. — "ioquatix (Samuel Williams)" <noreply@...>

SXNzdWUgIzE5MDI2IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGlvcXVhdGl4IChTYW11ZWwgV2lsbGlh

10 messages 2022/09/28

[#110133] [Ruby master Bug#19028] GCC12 Introduces new warn flags `-Wuse-after-free` — "eightbitraptor (Matthew Valentine-House)" <noreply@...>

SXNzdWUgIzE5MDI4IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGVpZ2h0Yml0cmFwdG9yIChNYXR0aGV3

8 messages 2022/09/28

[#110145] [Ruby master Misc#19030] [ANN] Migrate lists.ruby-lang.org to Google Groups — "hsbt (Hiroshi SHIBATA)" <noreply@...>

SXNzdWUgIzE5MDMwIGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGhzYnQgKEhpcm9zaGkgU0hJQkFUQSku

12 messages 2022/09/29

[#110154] [Ruby master Bug#19033] One-liner pattern match as Boolean arg syntax error — "baweaver (Brandon Weaver)" <noreply@...>

SXNzdWUgIzE5MDMzIGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGJhd2VhdmVyIChCcmFuZG9uIFdlYXZl

7 messages 2022/09/30

[ruby-core:110000] [Ruby master Feature#19008] Introduce coverage support for `eval`.

From: "mame (Yusuke Endoh)" <noreply@...>
Date: 2022-09-22 20:46:37 UTC
List: ruby-core #110000
Issue #19008 has been updated by mame (Yusuke Endoh).


We discussed this proposal at the dev meeting, and @matz decided to give it a try.

@ioquatix has been merged the PR, but I noticed two additional problems:

## 1. eval may discard existing file coverage data

```ruby
require "coverage"

Coverage.start

load "tt.rb"

# the content of tt.rb
#
#   1: 100.times do
#   2:   1
#   3: end

# The coverage of tt.rb is gathered correctly
p Coverage.result(reset: false) #=> {"tt.rb"=>[1, 100, nil]}

# Call eval with a file "tt.rb"
eval(<<SRC, nil, "tt.rb", 1)
p 1
p 2
p 3
SRC

# The gathered coverage is discarded, and overwritten with a new coverage data for eval 
p Coverage.result #=> {"tt.rb"=>[1, 1, 1]}
```

I am unsure what behavior is desirable here, but at least I think it should not discard the old coverage for a file. I think a file coverage is more important than an eval coverage.

I propose three possible solutions:

* 1. Do not record an eval coverage when a file coverage already exists. (And if a file is required after eval, overwrite an eval coverage with a file coverage)
* 2. Accumulate the two data (It is inaccurate, but it is maybe better than current)
* 3. Record the data for eval as another key (This will break some coverage tools because it changes the type of keys)

```
# Solution 1
p Coverage.result #=> {"tt.rb"=>[1, 100, nil]}

# Solution 2
p Coverage.result #=> {"tt.rb"=>[2, 101, 1]}

# Solution 3
p Coverage.result #=> {"tt.rb"=>[1, 100, nil], [:eval, "tt.rb"]=>[1, 1, 1]}
```

Personally, I like Solution 1.


## 2. branch coverage with ERB does not work well

Branch coverage includes column information, but this will not work well with ERB, because ERB generate code to keep row numbers, but it does not keep column numbers (it is almost impossible).

I think this would be difficult to resolve. So I guess the only thing we can do is to document it.


@ioquatix What do you think? Can you create an additional patch?

----------------------------------------
Feature #19008: Introduce coverage support for `eval`.
https://bugs.ruby-lang.org/issues/19008#change-99252

* 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: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread