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

[ruby-core:117188] [Ruby master Bug#20340] Ractor comments not applying to constant targets
by kddnewton (Kevin Newton) 13 Mar '25

13 Mar '25

Issue #20340 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20340: Ractor comments not applying to constant targets https://bugs.ruby-lang.org/issues/20340 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In this example: ```ruby C, = { foo: bar } ``` You get: ``` == disasm: #<ISeq:<main>@test.rb:1 (1,0)-(1,17)> 0000 putobject :foo ( 1)[Li] 0002 putself 0003 opt_send_without_block <calldata!mid:bar, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0005 newhash 2 0007 dup 0008 expandarray 1, 0 0011 putspecialobject 3 0013 setconstant :C 0015 leave ``` But there's no difference from: ```ruby # shareable_constant_value: literal C, = { foo: bar } ``` I would have expected: ``` == disasm: #<ISeq:<main>@test.rb:1 (1,0)-(2,16)> 0000 putobject RubyVM::FrozenCore ( 2)[Li] 0002 putobject :foo 0004 putobject RubyVM::FrozenCore 0006 putself 0007 opt_send_without_block <calldata!mid:bar, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0009 putobject "C" 0011 opt_send_without_block <calldata!mid:ensure_shareable, argc:2, ARGS_SIMPLE> 0013 newhash 2 0015 opt_send_without_block <calldata!mid:make_shareable, argc:1, ARGS_SIMPLE> 0017 dup 0018 expandarray 1, 0 0021 putspecialobject 3 0023 setconstant :C 0025 leave ``` Is this omission intentional? For context, I'm building this in prism and I need to know if I should explicitly disable this behavior. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:113153] [Ruby master Bug#19584] Crash in rb_gc_register_address
by peterzhu2118 (Peter Zhu) 13 Mar '25

13 Mar '25

Issue #19584 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #19584: Crash in rb_gc_register_address https://bugs.ruby-lang.org/issues/19584 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/7670 Some C extensions pass a pointer to a global variable to rb_gc_register_address. However, if a GC is triggered inside of rb_gc_register_address, then the object could get swept since it does not exist on the stack. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:115512] [Ruby master Bug#20025] Parsing identifiers/constants is case-folding dependent
by kddnewton (Kevin Newton) 13 Mar '25

13 Mar '25

Issue #20025 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20025: Parsing identifiers/constants is case-folding dependent https://bugs.ruby-lang.org/issues/20025 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When CRuby parses identifiers, it is encoding-dependent. Once the identifier is found, it determines if it starts with a uppercase or lowercase codepoint. This determines if the identifier is a constant or not. The function is charge of this is `rb_sym_constant_char_p`. For non-unicode encodings where the leading byte has the top-bit set, this relies on onigmo's `mbc_case_fold` to determine if it is a constant or not (as opposed to `is_code_ctype`). This works for almost every single codepoint in every encoding, but has one very weird edge case. In the Windows-1253 encoding for the 0xB5 byte, it's the micro sign. The micro sign, when case folded, becomes the uppercase mu character, and then the lowercase mu character, or 0xEC. This means that even though 0xB5 reports itself as being a lowercase codepoint, it gets parsed as a constant. This example might make this more clear: ``` ruby class Context < BasicObject def method_missing(name, *) = :identifier def self.const_missing(name) = :constant end encoding = Encoding::Windows_1253 character = 0xB5.chr(encoding) source = "# encoding: #{encoding.name}\n#{character}\n" result = Context.new.instance_eval(source) puts "#{encoding.name} encoding of 0x#{character.ord.to_s(16).upcase}" puts " [[:alpha:]] => #{character.match?(/[[:alpha:]]/)}" puts " [[:alnum:]] => #{character.match?(/[[:alnum:]]/)}" puts " [[:upper:]] => #{character.match?(/[[:upper:]]/)}" puts " [[:lower:]] => #{character.match?(/[[:lower:]]/)}" puts " parsed as #{result}" ``` this results in the output of: ``` Windows-1253 encoding of 0xB5 [[:alpha:]] => true [[:alnum:]] => true [[:upper:]] => false [[:lower:]] => true parsed as constant ``` To be clear, I don't think the case-folding is incorrect here (and @duerst confirms that it is correct). I believe instead that it is incorrect to use case-folding here to determine if a codepoint is uppercase or not. Note that this only impacts this one codepoint in this one encoding, so I don't believe this is actually a large-scale problem. But I found it surprising, and think we should change it. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:112301] [Ruby master Bug#19426] Endless `Range#step` of object with `#succ` method does not work
by nobu (Nobuyoshi Nakada) 13 Mar '25

13 Mar '25

Issue #19426 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19426: Endless `Range#step` of object with `#succ` method does not work https://bugs.ruby-lang.org/issues/19426 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Consider this `c` object which hash `#succ` method. ```ruby c = Struct.new(:i) do def succ; self.class.new(i+1); end def <=>(other) i <=> other.i;end end.new(0) ``` This `Range#step` works. ```ruby (c..c.succ).step(1) do |d| p d.i # 0, 1 end ``` But it fails on an endless range. ```ruby (c..).step(1) do |d| p d.i break if d.i > 3 end ``` ``` -:3:in `<=>': undefined method `i' for nil:NilClass (NoMethodError) from -:10:in `step' from -:10:in `<main>' ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:116369] [Ruby master Feature#20202] Memoized endless method definitions
by matheusrich (Matheus Richard) 27 Feb '25

27 Feb '25

Issue #20202 has been reported by matheusrich (Matheus Richard). ---------------------------------------- Feature #20202: Memoized endless method definitions https://bugs.ruby-lang.org/issues/20202 * Author: matheusrich (Matheus Richard) * Status: Open * Priority: Normal ---------------------------------------- I propose introducing a shorthand for memoized endless method definitions: ```rb class Foo def bar ||= :memoized_value # It should behave like def bar = (@bar ||= :memoized_value) end ``` Not only is this shorter and (IMO) a natural follow-up for endless method definitions, but it's also a common pattern on Ruby codebases. It's very useful to decompose responsibilities into several objects: ```rb class User def notifications_enabled? = settings.notifications? def enable_notifications = (settings.notifications = true) def disable_notifications = (settings.notifications = false) private def settings = @settings ||= Settings.new(self) end class User::Settings attr_writer :notifications def initialize(user) @user = user @notifications = false end def notifications? = @notifications end u = User.new u.notifications_enabled? # => false u.enable_notifications u.notifications_enabled? # => true ``` In the example, the `settings` method could be rewritten as ```rb def settings ||= Settings.new(self) ``` -- https://bugs.ruby-lang.org/

4 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:115117] [Ruby master Bug#19967] Already installed libruby.dylib is used for test on macOS
by nobu (Nobuyoshi Nakada) 24 Jan '25

24 Jan '25

Issue #19967 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19967: Already installed libruby.dylib is used for test on macOS https://bugs.ruby-lang.org/issues/19967 * Author: nobu (Nobuyoshi Nakada) * Status: Assigned * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- On macOS, in the case of `--enable-shared` and `--disable-load-relative`, already install libruby.dylib is used during tests if exists. This is because since [Bug #14992], `DYLD_FALLBACK_LIBRARY_PATH` is used instead of `DYLD_LIBRARY_PATH`. The latter environment variable is used preferentially, whereas the former is used as a fallback, as the name implies. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:116640] [Ruby master Feature#20249] Print only backtraces in rb_bug(), by default
by osyoyu (Daisuke Aritomo) 23 Jan '25

23 Jan '25

Issue #20249 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Feature #20249: Print only backtraces in rb_bug(), by default https://bugs.ruby-lang.org/issues/20249 * Author: osyoyu (Daisuke Aritomo) * Status: Open * Priority: Normal ---------------------------------------- ## Background When a segfault or some unexpected situation occurs, `rb_bug()` is called and prints some few hundred to thousands of lines. The most helpful parts are (arguably) "Ruby level backtrace information" and "C-level backtrace information", but those parts are buried in the very lengthy report. In particular, the "Other runtime information" which contains the list of loaded features (scripts?) and the process memory map could be extremely long despite it does not come very useful, at least when developing C extensions. Even a minimal report from a simple script would consist of 250 lines and require 7 PgUps on my MacBook Air (13 inch) to reach the backtrace part, which contains all the information I need. ## Proposal My proposal is to default to a "minimal report" mode with a limited set of sections, perhaps only "Ruby level backtrace information" and "C level backtrace information" only When a full report is desired (i.e. for bug reports), the user could re-run the script with an special environment variable, such as `RUBY_FULL_CRASH_REPORT=1`. Rust implmements a similar pattern. It doesn't print the full backtrace on panics by default; instead, it guides the user to re-run the program with `RUST_BACKTRACE=1`. It might be hard to reproduce some crashes and segfaults, especially in long-running daemons. It might be nice to default to the "full" mode when stdout is not a tty, since daemons tend to run in non-tty environments. ## Appendix A typical crash report would look like this: ``` ../../example.rb: [BUG] ruby 3.4.0dev (2024-01-20T15:27:19Z master 366b14c0cd) [arm64-darwin23] -- Crash Report log information -------------------------------------------- (5 lines) -- Control frame information ----------------------------------------------- (~50 lines) -- Ruby level backtrace information ---------------------------------------- (depends on program; typically ~50 lines in Rails) -- C level backtrace information ------------------------------------------- (50+-ish lines, depends on program) -- Machine register context ------------------------------------------------ (~10 lines) -- Threading information --------------------------------------------------- (2 lines) -- Other runtime information ----------------------------------------------- * Loaded script (1 line) * Loaded features (depends on program; 800+ lines in Rails) * Process memory map (depends on environment; around 200 lines?) -- https://bugs.ruby-lang.org/

5 10

[ruby-core:111121] [Ruby master Bug#19165] Method (with no param) delegation with *, **, and ... is slow
by matsuda (Akira Matsuda) 16 Jan '25

16 Jan '25

Issue #19165 has been reported by matsuda (Akira Matsuda). ---------------------------------------- Bug #19165: Method (with no param) delegation with *, **, and ... is slow https://bugs.ruby-lang.org/issues/19165 * Author: matsuda (Akira Matsuda) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-12-01T08:05:41Z master 4e68b59431) +YJIT [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I found that method delegation via Forwardable is much slower than normal method call when delegating a method that does not take parameters. Here's a benchmark that explains what I mean. ``` require 'forwardable' require 'pp' require 'benchmark/ips' class Obj extend Forwardable attr_accessor :other def initialize @other = Other.new end def foo_without_splat @other.foo end def foo_with_splat(*) @other.foo(*) end def foo_with_splat_with_name(*args) @other.foo(*args) end def foo_with_splat_and_double_splat(*, **) @other.foo(*, **) end def foo_with_triple_dots(...) @other.foo(...) end delegate :foo => :@other end class Other def foo() end end o = Obj.new Benchmark.ips do |x| x.report 'simple call' do o.other.foo end x.report 'delegate without splat' do o.foo_without_splat end x.report 'delegate with splat' do o.foo_with_splat end x.report 'delegate with splat with name' do o.foo_with_splat_with_name end x.report 'delegate with splat and double splat' do o.foo_with_splat_and_double_splat end x.report 'delegate with triple dots' do o.foo_with_triple_dots end x.report 'delegate via forwardable' do o.foo end end (result) simple call 38.918M (± 0.9%) i/s - 194.884M delegate without splat 31.933M (± 1.6%) i/s - 159.611M delegate with splat 10.269M (± 1.6%) i/s - 51.631M delegate with splat with name 9.888M (± 1.0%) i/s - 49.588M delegate with splat and double splat 4.117M (± 0.9%) i/s - 20.696M delegate with triple dots 4.169M (± 0.9%) i/s - 20.857M delegate via forwardable 9.204M (± 2.1%) i/s - 46.295M ``` It shows that Method delegation with a splat is 3-4 times slower (regardless of whether the parameter is named or not), and delegation with a triple-dot literal is 9-10 times slower than a method delegation without an argument. This may be because calling a method taking a splat always assigns an Array object even when no actual argument was given, and calling a method taking triple-dots assigns five Array objects and two Hash objects (this is equivalent to `*, **`). Are there any chance reducing these object assignments and making them faster? My concern is that the Rails framework heavily uses this kind of method delegations, and presumably it causes unignorable performance overhead. -- https://bugs.ruby-lang.org/

6 8