May 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:118015] [Ruby master Bug#20510] File.open mode argument inconsistency
by akr (Akira Tanaka) 25 May '24

25 May '24

Issue #20510 has been reported by akr (Akira Tanaka). ---------------------------------------- Bug #20510: File.open mode argument inconsistency https://bugs.ruby-lang.org/issues/20510 * Author: akr (Akira Tanaka) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found that `File.new(1, mode: File::WRONLY, path: "foo")` succeeds but `File.new(1, File::WRONLY, path: "foo")` fails. It is inconsistent. I think they should both succeed. ``` % ./ruby -e 'p File.new(1, mode: File::WRONLY, path: "foo")' #<File:foo> % ./ruby -e 'p File.new(1, File::WRONLY, path: "foo")' -e:1:in 'File#initialize': no implicit conversion of Integer into String (TypeError) p File.new(1, File::WRONLY, path: "foo") ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ from -e:1:in 'IO.new' from -e:1:in '<main>' % ./ruby -v ruby 3.4.0dev (2024-05-25T02:25:56Z tempfile-create-io 99463a8400) [x86_64-linux] ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117368] [Ruby master Bug#20401] Duplicated when clause warning line number
by kddnewton (Kevin Newton) 24 May '24

24 May '24

Issue #20401 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20401: Duplicated when clause warning line number https://bugs.ruby-lang.org/issues/20401 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When you have a duplicated when clause, you get a warning for it. For example: ```ruby case foo when :bar when :baz when :bar end ``` you get `warning: duplicated `when' clause with line 2 is ignored`. But the when clause that is ignored is the one on line 4, not line 2. It seems like it's warning for the wrong line. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:115014] [Ruby master Bug#19920] Ruby 3.1 fails to build with --enable-shared on macos-arm64: is an incompatible architecture (have 'arm64', need '')
by Eregon (Benoit Daloze) 23 May '24

23 May '24

Issue #19920 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19920: Ruby 3.1 fails to build with --enable-shared on macos-arm64: is an incompatible architecture (have 'arm64', need '') https://bugs.ruby-lang.org/issues/19920 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- See https://github.com/ruby/ruby-builder/actions/runs/6494296018/job/1763696879… ``` installing bundled gems: /Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib/ruby/gems/3.1.0 minitest 5.15.0 power_assert 2.0.1 rake 13.0.6 test-unit 3.5.3 rexml 3.2.5 rss 0.2.9 net-ftp 0.1.3 net-imap 0.2.3 net-pop 0.1.1 net-smtp 0.3.1 matrix 0.4.2 prime 0.1.2 rbs 2.7.0 Building native extensions. This could take a while... /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:102:in `run': ERROR: Failed to build gem native extension. (Gem::Ext::BuildError) current directory: /Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib/ruby/gems/3.1.0/gems/rbs-2.7.0/ext/rbs_extension /Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/bin/ruby -I /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib extconf.rb checking for whether -std=c99 is accepted as CFLAGS... *** extconf.rb failed *** Could not create Makefile due to some reason, probably lack of necessary libraries and/or headers. Check the mkmf.log file for more details. You may need configuration options. Provided configuration options: --with-opt-dir --without-opt-dir --with-opt-include --without-opt-include=${opt-dir}/include --with-opt-lib --without-opt-lib=${opt-dir}/lib --with-make-prog --without-make-prog --srcdir=. --curdir --ruby=/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/bin/$(RUBY_BASE_NAME) /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:490:in `try_do': The compiler failed to generate an executable file. (RuntimeError) You have to install development tools first. from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:616:in `block in try_compile' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:563:in `with_werror' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:616:in `try_compile' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:680:in `try_cflags' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:1025:in `block (2 levels) in append_cflags' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:989:in `block in checking_for' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:354:in `block (2 levels) in postpone' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:324:in `open' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:354:in `block in postpone' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:324:in `open' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:350:in `postpone' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:988:in `checking_for' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:1024:in `block in append_cflags' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:1023:in `each' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:1023:in `append_cflags' from extconf.rb:3:in `<main>' To see why this extension failed to compile, please check the mkmf.log which can be found here: /Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib/ruby/gems/3.1.0/extensions/arm64-darwin-22/3.1.0/rbs-2.7.0/mkmf.log extconf failed, exit code 1 Gem files will remain installed in /Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib/ruby/gems/3.1.0/gems/rbs-2.7.0 for inspection. Results logged to /Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib/ruby/gems/3.1.0/extensions/arm64-darwin-22/3.1.0/rbs-2.7.0/gem_make.out from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/ext_conf_builder.rb:28:in `build' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:171:in `build_extension' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:205:in `block in build_extensions' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:202:in `each' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:202:in `build_extensions' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/installer.rb:843:in `build_extensions' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/installer.rb:326:in `install' from ./tool/rbinstall.rb:899:in `block in install' from ./tool/rbinstall.rb:713:in `no_write' from ./tool/rbinstall.rb:899:in `install' from ./tool/rbinstall.rb:1063:in `block (2 levels) in <main>' from ./tool/rbinstall.rb:1044:in `foreach' from ./tool/rbinstall.rb:1044:in `block in <main>' from ./tool/rbinstall.rb:1119:in `block in <main>' from ./tool/rbinstall.rb:1116:in `each' from ./tool/rbinstall.rb:1116:in `<main>' /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:102:in `run': extconf failed, exit code 1 (Gem::InstallError) from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/ext_conf_builder.rb:28:in `build' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:171:in `build_extension' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:205:in `block in build_extensions' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:202:in `each' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:202:in `build_extensions' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/installer.rb:843:in `build_extensions' from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/installer.rb:326:in `install' from ./tool/rbinstall.rb:899:in `block in install' from ./tool/rbinstall.rb:713:in `no_write' from ./tool/rbinstall.rb:899:in `install' from ./tool/rbinstall.rb:1063:in `block (2 levels) in <main>' from ./tool/rbinstall.rb:1044:in `foreach' from ./tool/rbinstall.rb:1044:in `block in <main>' from ./tool/rbinstall.rb:1119:in `block in <main>' from ./tool/rbinstall.rb:1116:in `each' from ./tool/rbinstall.rb:1116:in `<main>' make: *** [do-install-nodoc] Error 1 BUILD FAILED (macOS 13.6 using ruby-build 20231012) ``` And the mkmf.log: ``` DYLD_FALLBACK_LIBRARY_PATH=.:/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib:/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4 "clang -o conftest -I/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/include/ruby-3.1.0/arm64-darwin22 -I/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/include/ruby-3.1.0/ruby/backward -I/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/include/ruby-3.1.0 -I. -I/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/include -DENABLE_PATH_CHECK=0 -I/opt/homebrew/opt/gmp/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -D_DARWIN_UNLIMITED_SELECT -D_REENTRANT -fdeclspec -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wdeprecated-declarations -Wdivision-by-zero -Wimplicit-function-declaration -Wimplicit-int -Wmisleading-indentation -Wpointer-arith -Wshorten-64-to-32 -Wwrite-strings -Wold-style-definition -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wunused-variable -Wextra-tokens -Wundef -fno-common -pipe conftest.c -L. -L/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib -L. -L/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib -fstack-protector-strong -L/opt/homebrew/opt/gmp/lib -lruby.3.1 " dyld[47952]: terminating because inserted dylib '/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/libruby.3.1.dylib' could not be loaded: tried: '/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/libruby.3.1.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need '')), '/System/Volumes/Preboot/Cryptexes/OS/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/libruby.3.1.dylib' (no such file), '/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/libruby.3.1.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need '')), './libruby.3.1.dylib' (no such file), '/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib/libruby.3.1.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need '')) dyld[47952]: tried: '/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/libruby.3.1.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need '')), '/System/Volumes/Preboot/Cryptexes/OS/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/libruby.3.1.dylib' (no such file), '/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/libruby.3.1.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need '')), './libruby.3.1.dylib' (no such file), '/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib/libruby.3.1.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need '')) checked program was: /* begin */ 1: #include "ruby.h" 2: 3: int main(int argc, char **argv) 4: { 5: return !!argv[argc]; 6: } /* end */ ``` I believe this bug has nothing to do with ruby-build except that ruby-build does `--enable-shared` by default. A known workaround is to use `--disable-shared`: https://github.com/rbenv/ruby-build/discussions/1961#discussioncomment-4031… Lots of other people met the same or similar issue as discussed there. Also discussed in https://github.com/ruby/rbs/issues/877 It would be nice if this could be fixed on the 3.1 branch. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:114062] [Ruby master Bug#19751] Ruby 3.2.2 Fails to Compile from Source
by martin_vahi (Martin Vahi) 23 May '24

23 May '24

Issue #19751 has been reported by martin_vahi (Martin Vahi). ---------------------------------------- Bug #19751: Ruby 3.2.2 Fails to Compile from Source https://bugs.ruby-lang.org/issues/19751 * Author: martin_vahi (Martin Vahi) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Details are at the attached file, but the build-crash-log seems to be: ``` compiling addr2line.c compiling dmyenc.c linking miniruby /bin/sh ./tool/ifchange "--timestamp=.rbconfig.time" rbconfig.rb rbconfig.tmp rbconfig.rb updated generating encdb.h encdb.h updated generating x86_64-linux-fake.rb ./template/fake.rb.in:19:in `eval': (eval):1: syntax error, unexpected backslash (SyntaxError) \\# 71 "./version.c" 3 ... ^ from ./template/fake.rb.in:19:in `value' from ./template/fake.rb.in:24:in `block (3 levels) in <main>' from ./template/fake.rb.in:23:in `scan' from ./template/fake.rb.in:23:in `block (2 levels) in <main>' from /home/mmmv/applications/Ruby/v_3_1_2/lib/ruby/3.1.0/erb.rb:905:in `eval' from /home/mmmv/applications/Ruby/v_3_1_2/lib/ruby/3.1.0/erb.rb:905:in `result' from ./tool/generic_erb.rb:36:in `block (2 levels) in <main>' from ./tool/generic_erb.rb:36:in `block in <main>' from ./tool/generic_erb.rb:29:in `map' from ./tool/generic_erb.rb:29:in `<main>' make: *** [uncommon.mk:791: x86_64-linux-fake.rb] Error 1 mmmv@hoidla01:~/tmp_/kompil/2023_03_30_v_3_2_2/ruby-3.2.2$ uname -a Linux hoidla01 4.19.0-22-amd64 #1 SMP Debian 4.19.260-1 (2022-09-29) x86_64 GNU/Linux mmmv@hoidla01:~/tmp_/kompil/2023_03_30_v_3_2_2/ruby-3.2.2$ ``` The source was the official one from the https://cache.ruby-lang.org/pub/ruby/3.2/ruby-3.2.2.tar.xz Thank You for reading this bug report :-) ---Files-------------------------------- Ruby_v_3_2_2_fails_to_compile.txt (31.6 KB) -- https://bugs.ruby-lang.org/

6 8

[ruby-core:116200] [Ruby master Bug#20183] `erb/escape.so` cannot be loaded when `--with-static-linked-ext`
by nobu (Nobuyoshi Nakada) 23 May '24

23 May '24

Issue #20183 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20183: `erb/escape.so` cannot be loaded when `--with-static-linked-ext` https://bugs.ruby-lang.org/issues/20183 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- Since `cgi/escape.c` and `erb/escape.c` are both initialized by `Init_escape()` functions, both call the same function in `extinit.c`. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:117658] [Ruby master Feature#20448] Make coverage event hooking C API public
by ms-tob (Matt S) 21 May '24

21 May '24

Issue #20448 has been reported by ms-tob (Matt S). ---------------------------------------- Feature #20448: Make coverage event hooking C API public https://bugs.ruby-lang.org/issues/20448 * Author: ms-tob (Matt S) * Status: Open ---------------------------------------- # Abstract Gathering code coverage information is a well-known goal within software engineering. It is most commonly used to assess code coverage during automated testing. A lesser known use-case is coverage-guided fuzz testing, which will be the primary use-case presented in this issue. This issue exists to request that Ruby coverage event hooking be made part of its official, public C API. # Background Ruby currently provides a number of avenues for hooking events *or* gathering coverage information: 1. The [Coverage](https://ruby-doc.org/3.3.0/exts/coverage/Coverage.html) module 2. The [TracePoint](https://ruby-doc.org/3.3.0/TracePoint.html) module 3. The [rb_add_event_hook](https://ruby-doc.org/3.3.0/extension_rdoc.html#label-Hoo… extension function Unfortunately, none of these pieces of functionality solve this issue's specific use-case. The `Coverage` module is not a great fit for real-time coverage analysis with an unknown start and stop point. Coverage-guided fuzz testing requires this. The `TracePoint` module and `rb_add_event_hook` are not able to hook branch and line coverage events. Coverage-guided fuzz testing typically tracks branch events. # Proposal The ultimate goal is to enable Ruby C extensions to process coverage events in real-time. I did some cursory investigation into the Ruby C internals to determine what it would take to achieve this, but I'm by no means an expert, so my list may be incomplete. The good news is that much of this functionality already exists, but it's part of the private, internal-only C API. 1. Make `RUBY_EVENT_COVERAGE_LINE` and `RUBY_EVENT_COVERAGE_BRANCH` public: https://github.com/ruby/ruby/blob/v3_3_0/vm_core.h#L2182-L2184 a. This would be an addition to the current public event types: https://github.com/ruby/ruby/blob/v3_3_0/include/ruby/internal/event.h#L32-… 2. Allow initializing global coverage state so that coverage tracking can be fully enabled a. Currently, if `Coverage.setup` or `Coverage.start` is not called, then coverage events cannot be hooked. I do not fully understand why this is, but I believe it has something to do with `rb_get_coverages` and `rb_set_coverages`. If calls to `rb_get_coverages` return `NULL` (https://github.com/ruby/ruby/blob/v3_3_0/iseq.c#L641-L647, https://github.com/ruby/ruby/blob/v3_3_0/iseq.c#L864-L868) then coverage hooking will not be enabled. I believe the `Coverage` module initializes that state via a `rb_set_coverages` call here: https://github.com/ruby/ruby/blob/v3_3_0/ext/coverage/coverage.c#L112-L120. b. So, to achieve this goal, a C extension would need to be able to call `rb_set_coverages` or somehow initialize the global coverage state. I've actually been able to achieve this functionality by calling undocumented features and defining `RUBY_EVENT_COVERAGE_BRANCH`: ```c #include <ruby.h> #include <ruby/debug.h> #define RUBY_EVENT_COVERAGE_BRANCH 0x020000 // ... rb_event_flag_t events = RUBY_EVENT_COVERAGE_BRANCH; rb_event_hook_flag_t flags = ( RUBY_EVENT_HOOK_FLAG_SAFE | RUBY_EVENT_HOOK_FLAG_RAW_ARG ); rb_add_event_hook2( (rb_event_hook_func_t) event_hook_branch, events, counter_hash, flags ); ``` If I call `Coverage.setup(branches: true)`, and add this event hook, then branch hooking works as expected. `rb_add_event_hook2` will still respect the `RUBY_EVENT_COVERAGE_BRANCH` value if its passed. But it would be better if I could rely on official functionality rather than undocumented features. The above two points would be requirements for this functionality, but there's an additional nice-to-have: 3. Extend the public `tracearg` functionality to include additional coverage information a. Currently, `tracearg` offers information like `rb_tracearg_lineno` and `rb_tracearg_path`. It would be helpful if it also provided additional coverage information like `coverage.c`'s column information and a unique identifier for each branch. Currently, I can only use `(path, lineno)` as a unique identifier for a branch because that's what's offered by the public API, but more information like column number would be helpful for uniquely identify branches. Since there can be multiple `if` statements on a single line, this can provide ambiguous identification for a branch event. # Use cases This use-case was born out of a new coverage-guided Ruby fuzzer: https://github.com/trailofbits/ruzzy. You can read more about its implementation details here: https://blog.trailofbits.com/2024/03/29/introducing-ruzzy-a-coverage-guided…. You can also find the Ruby C extension code behind its implementation here: https://github.com/trailofbits/ruzzy/blob/v0.7.0/ext/cruzzy/cruzzy.c#L220-L…. So, the primary use-case here is enabling real-time, coverage-guided fuzz testing of Ruby code. However, as mentioned in the abstract, gathering code coverage information is useful in many domains. For example, it could enable new workflows in standard unit/integration test coverage. It could also enable gathering coverage information in real-time as an application is running. I see this as the most generalized form of gathering code coverage information, and something like the `Coverage` module as a specialized implementation. Another example, https://bugs.ruby-lang.org/issues/20282 may be solved by this more generalized solution. We are tracking this request downstream here: https://github.com/trailofbits/ruzzy/issues/9 # Discussion Fuzz testing is another tool in a testers toolbelt. It is an increasingly common way to improve software's robustness. Go has it built in to the standard library, Python has Atheris, Java has Jazzer, JavaScript has Jazzer.js, etc. OSS-Fuzz has helped identify and fix over 10,000 vulnerabilities and 36,000 bugs [using fuzzing](https://google.github.io/oss-fuzz/#trophies). Ruby deserves a good fuzzer, and improving coverage gathering would help achieve that goal. The `Coverage` module, `TracePoint` module, and `rb_add_event_hook` function seem like they could fulfill this goal. However, after deeper investigation, none of them fit the exact requirements for this use-case. # See also - https://bugs.ruby-lang.org/issues/20282 - https://github.com/google/atheris - https://security.googleblog.com/2020/12/how-atheris-python-fuzzer-works.html - https://github.com/CodeIntelligenceTesting/jazzer/ - https://www.code-intelligence.com/blog/java-fuzzing-with-jazzer - https://go.dev/doc/security/fuzz/ -- https://bugs.ruby-lang.org/

2 8

[ruby-core:116026] [Ruby master Bug#20151] Can't build Ruby 3.1 on FreeBSD 14.0
by hsbt (Hiroshi SHIBATA) 21 May '24

21 May '24

Issue #20151 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20151: Can't build Ruby 3.1 on FreeBSD 14.0 https://bugs.ruby-lang.org/issues/20151 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I couldn't install Ruby 3.1.3 on FreeBSD 14.0. ``` compiling util.c util.c:255:1: error: expected identifier or '(' ruby_qsort(void* base, const size_t nel, const size_t size, cmpfunc_t *cmp, void *d) ^ ./include/ruby/util.h:124:21: note: expanded from macro 'ruby_qsort' # define ruby_qsort qsort_r ^ /usr/include/stdlib.h:356:5: note: expanded from macro 'qsort_r' __generic(arg5, int (*)(void *, const void *, const void *), \ ^ /usr/include/sys/cdefs.h:322:2: note: expanded from macro '__generic' _Generic(expr, t: yes, default: no) ^ 1 error generated. *** Error code 1 Stop. ``` Compiler version is here: ``` FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152) ``` I could install Ruby 3.2.2. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:117901] [Ruby master Feature#20492] Debug option for tempfile
by hadmut (Hadmut Danisch) 19 May '24

19 May '24

Issue #20492 has been reported by hadmut (Hadmut Danisch). ---------------------------------------- Feature #20492: Debug option for tempfile https://bugs.ruby-lang.org/issues/20492 * Author: hadmut (Hadmut Danisch) * Status: Open ---------------------------------------- Hi, the ruby lib tempfile is quite useful, but since it always deletes files once the object is garbage collected or the program terminates (or the program explicitely asks to remove the file) it is difficult to debug programs and to check the file contents, after program termination. Replacing all tempfile uses with regular file operations is awkward. It therefore would be useful, if file deletion of tempfiles could be completely turned of e.g. through an environment variable or by the program itself, like through a --debug option or when catching errors, like deleting all files during normal program termination, but not if there's a runtime error. regards -- https://bugs.ruby-lang.org/

3 2

[ruby-core:114070] [Ruby master Bug#19753] IO::Buffer#get_string can't handle negative offset
by noteflakes (Sharon Rosner) 18 May '24

18 May '24

Issue #19753 has been reported by noteflakes (Sharon Rosner). ---------------------------------------- Bug #19753: IO::Buffer#get_string can't handle negative offset https://bugs.ruby-lang.org/issues/19753 * Author: noteflakes (Sharon Rosner) * Status: Open * Priority: Normal * ruby -v: 3.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby irb(main):001:0> b = IO::Buffer.for('abc') => #<IO::Buffer 0x00007f858f5450c0+3 EXTERNAL READONLY SLICE> ... irb(main):002:0> b.get_string(-1) => "\x00abc" irb(main):003:0> b.get_string(-1000, 3) (irb):3:in `get_string': Specified offset+length exceeds data size! (ArgumentError) from (irb):3:in `<main>' from /home/sharon/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/irb-1.7.1/exe/irb:9:in `<top (required)>' from /home/sharon/.rbenv/versions/3.2.0/bin/irb:25:in `load' from /home/sharon/.rbenv/versions/3.2.0/bin/irb:25:in `<main>' ``` Using a negative offset returns garbage in the string but it also might segfault: ```ruby irb(main):003:0> b = IO::Buffer.map(File.open('sgt-nodes.sql', 'r+')) => #<IO::Buffer 0x00007f189de14000+2008858 EXTERNAL MAPPED SHARED> irb(main):004:0> b.get_string(-1000) (irb):4: [BUG] Segmentation fault at 0x00007f189de13c18 ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0021 p:---- s:0109 e:000108 CFUNC :get_string ... ``` ## Expected behaviour I think it might be nice to have `#get_string` behave like other methods taking an offset, like `String#[]`. For example: ```ruby irb(main):001:0> b = IO::Buffer.for('abc') => #<IO::Buffer 0x00007f858f5450c0+3 EXTERNAL READONLY SLICE> ... irb(main):002:0> b.get_string(-1) => "c" irb(main):003:0> b.get_string(-2) => "bc" irb(main):003:0> b.get_string(-1000) => "abc" irb(main):003:0> b.get_string(-1000, 2) => "ab" ``` -- https://bugs.ruby-lang.org/

5 9

[ruby-core:117835] [Ruby master Feature#20484] A new pragma for eager resolution of classes referenced in rescue clauses.
by jfrisby (Jon Frisby) 16 May '24

16 May '24

Issue #20484 has been reported by jfrisby (Jon Frisby). ---------------------------------------- Feature #20484: A new pragma for eager resolution of classes referenced in rescue clauses. https://bugs.ruby-lang.org/issues/20484 * Author: jfrisby (Jon Frisby) * Status: Open ---------------------------------------- I've been using Ruby for 20 years, and just today learned (the hard way) that the class name(s) referenced in a `rescue` clause are not resolved until an exception occurs. Upon reflection, this behavior probably makes sense in a lot of situations. Late resolution may simplify code loading for the developer. I would, however, love to see an opt-in feature (a la `frozen-string-literal`) to force resolution when the code is loaded/parsed. -- https://bugs.ruby-lang.org/

4 5