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

[ruby-core:120335] [Ruby master Feature#20971] Deprecate `rb_path_check`
by Earlopain (Earlopain _) 14 Feb '25

14 Feb '25

Issue #20971 has been reported by Earlopain (Earlopain _). ---------------------------------------- Feature #20971: Deprecate `rb_path_check` https://bugs.ruby-lang.org/issues/20971 * Author: Earlopain (Earlopain _) * Status: Open ---------------------------------------- With #16131, various code around $SAFE, taint, etc. has been deprecated and removed. GH PR https://github.com/ruby/ruby/pull/2476. Now, [`rb_path_check`] still exists as part of the public API, with Ruby itself never using or testing it. I believe it should have been deprecated and was simply missed. Should it be deprecated today or is that not worth the effort? Docs for it are pretty vague: https://github.com/ruby/ruby/blob/33f95d632dce42fac35da29eaed33f0a5a4f0dcb/… > This function is mysterious. What it does is not immediately obvious. Also what it does seems platform dependent. [`rb_path_check`]: https://github.com/ruby/ruby/blob/33f95d632dce42fac35da29eaed33f0a5a4f0dcb/… -- https://bugs.ruby-lang.org/

5 12

[ruby-core:120409] [Ruby master Feature#20982] Inconsistency between Hash#inspect and ENV.inspect in Ruby 3.4
by herwin (Herwin W) 14 Feb '25

14 Feb '25

Issue #20982 has been reported by herwin (Herwin W). ---------------------------------------- Feature #20982: Inconsistency between Hash#inspect and ENV.inspect in Ruby 3.4 https://bugs.ruby-lang.org/issues/20982 * Author: herwin (Herwin W) * Status: Open ---------------------------------------- Ruby 3.4 changed the stringified output of Hash to add whitespace to the hashrockets ``` ruby -e 'p({"a"=>"b"})' {"a" => "b"} ``` The output of `ENV.inspect` is very similar to `Hash#inspect`, but does not include the whitespace ``` ruby -e 'p ENV' {"SHELL"=>"/bin/bash", [...] } ``` Adding the extra whitespace around the hashrockets would improve the readability, and make things more consistent. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:120458] [Ruby master Misc#20995] exception escapes block given to IO.popen("-") in child process
by martin.dorey＠hds.com (Martin Dorey) 14 Feb '25

14 Feb '25

Issue #20995 has been reported by martin.dorey(a)hds.com (Martin Dorey). ---------------------------------------- Misc #20995: exception escapes block given to IO.popen("-") in child process https://bugs.ruby-lang.org/issues/20995 * Author: martin.dorey(a)hds.com (Martin Dorey) * Status: Open ---------------------------------------- I was surprised by the "ensure" being reached in the child process here: ``` ruby martind@stormy:~/tmp/D161730$ cat repro.rb #!/usr/bin/ruby -w parent = Process.pid() [false, true].each() { |nauseous| $stderr.puts("#{nauseous ? "" : "not "}raising exception from child:") begin IO.popen("-") { |io| unless io if nauseous raise("childish fit") end end } ensure $stderr.puts("in finalization block from #{Process.pid() == parent ? "parent" : "child"}") $stderr.puts() end } martind@stormy:~/tmp/D161730$ ~/download/ruby-3.3.4/ruby --version ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux] martind@stormy:~/tmp/D161730$ ~/download/ruby-3.3.4/ruby -w repro.rb not raising exception from child: in finalization block from parent raising exception from child: in finalization block from child repro.rb:11:in `block (2 levels) in <main>': childish fit (RuntimeError) from repro.rb:7:in `popen' from repro.rb:7:in `block in <main>' from repro.rb:3:in `each' from repro.rb:3:in `<main>' in finalization block from parent martind@stormy:~/tmp/D161730$ ``` In the first iteration of the loop, we don't see the surprise - the child process exits when the block is completed. Only when an exception is thrown, in the second iteration, does the control flow escape from the block. It does so even for the SystemExit exception raised by exit(0) but not, as we see above, from just leaving the block (in which case perhaps we _exit(0) at https://github.com/ruby/ruby/blob/master/io.c#L8044) My expectation was that the block would be executed in the child process much like the "main" part of a program, with the usual unhandled exception reporting, which we see demonstrated above, being invoked as soon as the exception propagated out the block, rather than first unwinding the callers. I think the behavior is unchanged since the oldest version I was conveniently able to test, which was: ruby 1.8.7 (2012-02-08 patchlevel 358) [x86_64-linux] ... so I didn't file this report as a Bug in case users have (accidentally?) come to depend on the behavior. I didn't find any mention of this at eg https://ruby-doc.org/3.4.1/IO.html#method-c-popen but I didn't file this report as a Feature request for the documentation in case the documentation deliberately leaves open such possibilities. I didn't even find anyone else puzzling over this behavior on eg StackOverflow, but I felt that I should report it for the benefit of the next poor sap to run into it, especially in case that's Future Me. Could it be a case where a warning would be worth more than the trouble it causes? -- https://bugs.ruby-lang.org/

4 6

[ruby-core:120443] [Ruby master Bug#20992] `eval(ascii_encoded_code)` raises EncodingError when multibyte local variable exists
by tompng (tomoya ishida) 14 Feb '25

14 Feb '25

Issue #20992 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20992: `eval(ascii_encoded_code)` raises EncodingError when multibyte local variable exists https://bugs.ruby-lang.org/issues/20992 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2024-12-28T09:40:37Z master e4ec2128ae) +YJIT +MN +PRISM [arm64-darwin22] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ~~~ruby #coding: utf-8 α=1 eval '1+2'.encode('ascii') ~~~ ~~~ $ ruby file.rb file.rb:3:in 'Kernel#eval': invalid symbol in encoding US-ASCII :"\xCE\xB1" (EncodingError) from file.rb:3:in '<main>' ~~~ Running the file below with `LANG=C ruby file.rb` will make IRB unresponsive ~~~ruby #coding: utf-8 α=1 binding.irb ~~~ ~~~ $ LANG=C ruby file.rb From: file.rb @ line 3 : 1: #coding: utf-8 2: α=1 => 3: binding.irb irb(main):001> 1 <internal:kernel>:168:in 'Kernel#loop': invalid symbol in encoding US-ASCII :"\xCE\xB1" (EncodingError) from <internal:prelude>:5:in 'Binding#irb' from file.rb:3:in '<main>' irb(main):002> ~~~ -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120432] [Ruby master Bug#20989] Segmentation fault in Ripper when lexing `/#{"\xcd"}/`
by Earlopain (Earlopain _) 14 Feb '25

14 Feb '25

Issue #20989 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #20989: Segmentation fault in Ripper when lexing `/#{"\xcd"}/` https://bugs.ruby-lang.org/issues/20989 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When I paste this code snippet into irb, I get a segfault: `/#{"\xcd"}/`. Current master (https://github.com/ruby/ruby/commit/adbbc9109ee71848204b5168a7c1bf604849e5fa) also fails. Here is a simple reproduction, I attached the full bug as an attachment: ```rb require "ripper" lexer = Ripper::Lexer.new('/#{"\xcd"}/', '-', 0) lexer.scan.each # => /home/earlopain/.rbenv/versions/3.4.1/lib/ruby/3.4.0/ripper/lexer.rb:177: [BUG] Segmentation fault at 0x0000000000000008 # => ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] ``` ---Files-------------------------------- bug.txt (27.2 KB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120404] [Ruby master Bug#20981] rb_undefine_finalizer is missing
by KitaitiMakoto 14 Feb '25

14 Feb '25

Issue #20981 has been reported by KitaitiMakoto (真北市). ---------------------------------------- Bug #20981: rb_undefine_finalizer is missing https://bugs.ruby-lang.org/issues/20981 * Author: KitaitiMakoto (真北市) * Status: Open * ruby -v: 3.4.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Merry Christmas! I encountered an error like "dyld[89037]: missing symbol called" in an extension which uses`rb_undefine_finalizer` in Ruby 3.4.1. It works fine in Ruby 3.3.6. The function defined in [ruby/include/ruby/internal/gc.h](https://github.com/ruby/ruby/blob/v3_4_1/i… but seems removed from [ruby/gc.c](https://github.com/ruby/ruby/blob/v3_4_1/gc.c). Could you consider restore the implementation or remove the function from `gc.h`? Reproducible code: ### extconf.rb ### ```ruby require "mkmf" create_makefile "undefine_finalizer_bug" ``` ### undefine_finalizer_bug.c ### ```c #include<ruby.h> static VALUE s_undefine_finalizer(VALUE self) { rb_undefine_finalizer(self); return Qnil; } void Init_undefine_finalizer_bug(void) { VALUE klass = rb_define_class("UndefineFinalizerBug", rb_cObject); rb_define_singleton_method(klass, "undefine_finalizer", s_undefine_finalizer, 0); } ``` ### undefine-finalizer-bug.rb ### ```ruby require "undefine_finalizer_bug.so" finalizer = proc { puts "Finalizer called" } ObjectSpace.define_finalizer(UndefineFinalizerBug, finalizer) UndefineFinalizerBug.new UndefineFinalizerBug.undefine_finalizer GC.start ``` ### Running ### #### Ruby 3.4.1 ## ``` % ruby ./extconf.rb && make && ruby -v -I. ./undefine-finalizer-bug.rb creating Makefile linking shared-object undefine_finalizer_bug.bundle ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] dyld[2436]: missing symbol called [1] 2436 abort ruby -v -I. ./undefine-finalizer-bug.rb ``` #### Ruby 3.3.6 #### ``` % chruby-exec 3.3.6 -- ruby ./extconf.rb && make && chruby-exec 3.3.6 -- ruby -v -I. ./undefine-finalizer-bug.rb creating Makefile linking shared-object undefine_finalizer_bug.bundle ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [arm64-darwin24] ``` Thank you. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:120047] [Ruby master Bug#20920] When loading a file, __FILE__ gets relative paths expanded only when they start with "./"
by deivid 13 Feb '25

13 Feb '25

Issue #20920 has been reported by deivid (David Rodríguez). ---------------------------------------- Bug #20920: When loading a file, __FILE__ gets relative paths expanded only when they start with "./" https://bugs.ruby-lang.org/issues/20920 * Author: deivid (David Rodríguez) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- $ cat foo.rb puts __FILE__ $ ruby foo.rb foo.rb $ ruby ./foo.rb ./foo.rb $ ruby -e 'load "foo.rb"' foo.rb $ ruby -e 'load "./foo.rb"' /full/path/to/foo.rb ``` More than an issue, this is mainly a question. In principle, it seems more consistent to me to either expand or not expand, but this is not causing real issues for me. I just want to figure out what to do with one pending spec in Bundler (https://github.com/rubygems/rubygems/blob/cd65092deb3168759820c613ecbc54cd9…) -- https://bugs.ruby-lang.org/

5 5

[ruby-core:113033] [Ruby master Feature#19555] Allow passing default options to `Data.define`
by p8 (Petrik de Heus) 13 Feb '25

13 Feb '25

Issue #19555 has been reported by p8 (Petrik de Heus). ---------------------------------------- Feature #19555: Allow passing default options to `Data.define` https://bugs.ruby-lang.org/issues/19555 * Author: p8 (Petrik de Heus) * Status: Open * Priority: Normal ---------------------------------------- Defining a subclass of `Data` with default attributes can currently be implemented by overriding `intialize`: ```ruby class Point < Data.define(:x, :y, :z) def initialize(x:, y:, z: 0) = super end p Point.new(1, 2) #=> #<data Point x=1, y=2, z=0> ``` It would be nice if we could do it in `define` as well: ```ruby Point = Data.define(:x, :y, z: 0) ``` -- https://bugs.ruby-lang.org/

5 6

[ruby-core:116983] [Ruby master Feature#20309] Bundled gems for Ruby 3.5
by hsbt (Hiroshi SHIBATA) 06 Feb '25

06 Feb '25

Issue #20309 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #20309: Bundled gems for Ruby 3.5 https://bugs.ruby-lang.org/issues/20309 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I propose migrate the following default gems to bundled gems at Ruby 3.5. So, It means users will get warnings if users try to load them. * ostruct * irb * reline * readline (wrapper file for readline-ext and reline) * io-console * logger * fiddle * pstore * open-uri * yaml (wrapper file for psych) * win32ole I have a plan to migrate the following default gems too. But I need to more feedback from other committers about them. * rdoc * We need to change build task like download rdoc gem before document generation. * or We make document generation is optional from Ruby 3.5 * We explicitly separate `make install` and `make install-doc` * un * `ruby -run` is one of cool feature of Ruby. Should we avoid uninstalling `un` gem? * singleton * This is famous design pattern. Should we enforce users add them to their Gemfile? * forwadable * `reline` needs to add forwardable their `runtime_dependency` after migration. * weakref * I'm not sure how impact after migrating bundled gems. * fcntl * Should we integrate these constants into ruby core? I would like to migrate `ipaddr` and `uri` too. But these are used by webrick that is mock server for our test suite. We need to rewrite `webrick` with `TCPSocker` or extract `ipaddr` and `uri` dependency from `webrick` Other default gems depend on our build process or other libraries deeply. I will update this proposal if I could extract them from default gems. -- https://bugs.ruby-lang.org/

9 27

[ruby-core:117765] [Ruby master Feature#20470] Extract Ruby's Garbage Collector
by peterzhu2118 (Peter Zhu) 29 Jan '25

29 Jan '25

Issue #20470 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #20470: Extract Ruby's Garbage Collector https://bugs.ruby-lang.org/issues/20470 * Author: peterzhu2118 (Peter Zhu) * Status: Open ---------------------------------------- # Extract Ruby's Garbage Collector ## Background As described in [[Feature #20351]](https://bugs.ruby-lang.org/issues/20351), we are working on the ability to plug alternative garbage collector implementations into Ruby. Our goal is to allow developers and researchers to create and experiment with new implementations of garbage collectors in Ruby in a simplified way. This will also allow experimentation with different GC implementations in production systems so users can choose the best GC implementation for their workloads. ## Implementation GitHub PR: [10721](https://github.com/ruby/ruby/pull/10721) In this patch, we have split the current `gc.c` file into two files: `gc.c` and `gc_impl.c`. `gc.c` now only contains code not specific to Ruby GC. This includes code to mark objects (which the GC implementation may choose not to use) and wrappers for internal APIs that the implementation may need to use (e.g. locking the VM). `gc_impl.c` now contains the implementation of Ruby's GC. This includes marking, sweeping, compaction, and statistics. Most importantly, `gc_impl.c` only uses public APIs in Ruby and a limited set of functions exposed in `gc.c`. This allows us to build `gc_impl.c` independently of Ruby and plug Ruby's GC into itself. ## Demonstration After [checking out the branch](https://github.com/ruby/ruby/pull/10721), we can first configure with `--with-shared-gc`: ```bash $ ./configure --with-shared-gc ... $ make -j ... ``` Let's now change the slot size of the GC to 64 bytes: ```bash $ sed -i 's/$#define BASE_SLOT_SIZE$.*/\1 64/' gc_impl.c ``` We can compile `gc_impl.c` independently using the following commands for clang or gcc (you may have to change the last `-I` to match your architecture and platform): ```bash $ clang -Iinclude -I. -I.ext/include/arm64-darwin23 -undefined dynamic_lookup -g -O3 -dynamiclib -o libgc.dylib gc_impl.c $ gcc -Iinclude -I. -I.ext/include/x86_64-linux -Wl,-undefined,dynamic_lookup -fPIC -g -O3 -shared -o libgc.so gc_impl.c ``` We can see that by default, the slot size is 40 bytes and objects are 40 bytes in size: ```bash $ ./ruby -e "puts GC.stat_heap(0, :slot_size)" 40 $ ./ruby -robjspace -e "puts ObjectSpace.dump(Object.new)" {"address":"0x1054a23f0", "type":"OBJECT", "shape_id":3, "slot_size":40, "class":"0x10528fd38", "embedded":true, "ivars":0, "memsize":40, "flags":{"wb_protected":true}} ``` We can now load our new GC using the `RUBY_GC_LIBRARY_PATH` environment variable (note that you may have to change the path to the DSO): ```bash $ RUBY_GC_LIBRARY_PATH=./libgc.dylib ./ruby -e "puts GC.stat_heap(0, :slot_size)" 64 $ RUBY_GC_LIBRARY_PATH=./libgc.dylib ./ruby -robjspace -e "puts ObjectSpace.dump(Object.new)" {"address":"0x1038de440", "type":"OBJECT", "shape_id":3, "slot_size":64, "class":"0x10355fc00", "embedded":true, "ivars":0, "memsize":64, "flags":{"wb_protected":true}} ``` ## Benchmark Benchmarks were ran on commit [c78cebb](https://github.com/ruby/ruby/commit/c78cebb469fe56b45ee5daad16ae97… on Ubuntu 22.04 using [yjit-bench](https://github.com/Shopify/yjit-bench/) on commit [cc5a76e](https://github.com/Shopify/yjit-bench/commit/cc5a76ef6240113650547…. Compiling gc_impl branch without `--with-shared-gc` (i.e. how the default Ruby is built), the benchmarks show little to no decrease in performance, with most of it being 0% to 1% slower: ``` -------------- ----------- ---------- ------------ ---------- --------------- -------------- bench master (ms) stddev (%) gc_impl (ms) stddev (%) gc_impl 1st itr master/gc_impl activerecord 73.9 0.3 74.6 0.3 1.00 0.99 chunky-png 911.1 0.2 937.2 0.2 0.97 0.97 erubi-rails 1582.4 0.1 1583.5 0.0 1.00 1.00 hexapdf 2716.2 1.1 2760.2 0.7 1.00 0.98 liquid-c 68.9 0.5 68.6 0.4 1.00 1.00 liquid-compile 67.9 0.1 68.2 0.2 0.99 1.00 liquid-render 172.8 0.1 174.9 0.1 0.99 0.99 lobsters 1033.9 0.4 1036.0 0.3 1.08 1.00 mail 135.1 0.2 136.5 0.2 0.99 0.99 psych-load 2250.8 0.1 2274.9 0.3 0.99 0.99 railsbench 2499.2 0.2 2502.9 0.1 1.00 1.00 rubocop 178.3 0.5 179.8 0.4 1.00 0.99 ruby-lsp 116.8 0.1 118.5 0.2 1.00 0.99 sequel 75.4 0.2 76.2 0.3 0.99 0.99 -------------- ----------- ---------- ------------ ---------- --------------- -------------- ``` Compiling gc_impl branch with `--with-shared-gc` and loading Ruby's current GC using `RUBY_GC_LIBRARY_PATH`, the benchmarks are still fairly good with performance decrease of only around 1% to 2%: ``` -------------- ----------- ---------- ------------ ---------- --------------- -------------- bench master (ms) stddev (%) gc_impl (ms) stddev (%) gc_impl 1st itr master/gc_impl activerecord 74.2 0.2 75.4 0.5 0.98 0.98 chunky-png 916.3 0.3 933.2 0.1 0.98 0.98 erubi-rails 1597.6 0.1 1586.3 0.2 1.01 1.01 hexapdf 2731.4 0.5 2776.8 0.7 1.00 0.98 liquid-c 68.5 0.1 68.9 0.4 0.97 0.99 liquid-compile 67.4 0.4 68.3 0.2 0.95 0.99 liquid-render 171.8 0.1 175.6 0.2 0.97 0.98 lobsters 1031.9 0.3 1041.4 0.3 0.94 0.99 mail 135.5 0.4 136.7 0.1 0.99 0.99 psych-load 2246.0 0.1 2281.3 0.1 0.99 0.98 railsbench 2490.9 0.0 2490.0 0.1 1.01 1.00 rubocop 179.8 2.3 180.0 0.4 0.94 1.00 ruby-lsp 117.3 0.1 118.5 0.1 0.99 0.99 sequel 75.8 0.5 76.3 0.2 0.99 0.99 -------------- ----------- ---------- ------------ ---------- --------------- -------------- ``` ## Limitations We recognize that our current implementation does not yet offer the flexibility required for a generic plug-in GC. Specifically, the set of APIs that the plug-in GC has to implement is relatively large, at around 70 functions. Additionally, some of these functions are specific to the current GC. We would like to emphasize that the API is NOT stable and is subject to change. We will be working on improving this API and reducing the surface area. This will be future work and we're not working on it in this phase. ## Future plans - Refactor and improve `gc_impl.c`. - Implement alternate GC implementations, such as the Epsilon GC and [MMTk](https://www.mmtk.io/) to prove that this API allows for alternate implementations of the GC. - Reduce and improve the API of the GC implementation. - Benchmark and improve performance of the DSO API. -- https://bugs.ruby-lang.org/

4 7