January 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:120765] [Ruby master Feature#21086] Declare rb_profile_frames() family as async-signal-safe
by osyoyu (Daisuke Aritomo) 23 Jan '25

23 Jan '25

Issue #21086 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Feature #21086: Declare rb_profile_frames() family as async-signal-safe https://bugs.ruby-lang.org/issues/21086 * Author: osyoyu (Daisuke Aritomo) * Status: Open ---------------------------------------- Since @ivoanjo 's change in https://github.com/ruby/ruby/pull/11036 , I believe `rb_profile_frames()` and `rb_profile_thread_frames()` could be marked as async-signal-safe. I remember @ko1 had a few reasons not to do so. I'd like to ask what @ko1 thinks now. -- https://bugs.ruby-lang.org/

1 1

[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:120715] [Ruby master Bug#21045] [patch & workaround] "make test-all" failed with FreeBSD 13.4
by hs (Hideki Sakamoto) 20 Jan '25

20 Jan '25

Issue #21045 has been reported by hs (Hideki Sakamoto). ---------------------------------------- Bug #21045: [patch & workaround] "make test-all" failed with FreeBSD 13.4 https://bugs.ruby-lang.org/issues/21045 * Author: hs (Hideki Sakamoto) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- "make test-all" fails when building Ruby 3.4.1 on FreeBSD 13.4. Build and test steps: <pre> % freebsd-version 13.4-RELEASE-p2 % tar xf ruby-3.4.1.tar.xz % cd ruby-3.4.1/ % ./configure % make % make test-all (snip) 1) Error: TestNetHTTPForceEncoding#test_response_body_encoding_encoding_without_content_type: Errno::ECONNREFUSED: Failed to open TCP connection to localhost:34716 (Connection refused - connect(2) for "localhost" port 34716) /tmp/ruby-3.4.1/lib/net/http.rb:1659:in 'TCPSocket#initialize' /tmp/ruby-3.4.1/lib/net/http.rb:1659:in 'IO.open' /tmp/ruby-3.4.1/lib/net/http.rb:1659:in 'block in Net::HTTP#connect' /tmp/ruby-3.4.1/lib/timeout.rb:185:in 'block in Timeout.timeout' /tmp/ruby-3.4.1/lib/timeout.rb:192:in 'Timeout.timeout' /tmp/ruby-3.4.1/lib/net/http.rb:1657:in 'Net::HTTP#connect' /tmp/ruby-3.4.1/lib/net/http.rb:1636:in 'Net::HTTP#do_start' /tmp/ruby-3.4.1/lib/net/http.rb:1625:in 'Net::HTTP#start' /tmp/ruby-3.4.1/lib/net/http.rb:2369:in 'Net::HTTP#request' /tmp/ruby-3.4.1/lib/net/http.rb:1984:in 'Net::HTTP#get' /tmp/ruby-3.4.1/test/net/http/test_http.rb:1344:in 'TestNetHTTPForceEncoding#fe_request' /tmp/ruby-3.4.1/test/net/http/test_http.rb:1372:in 'TestNetHTTPForceEncoding#test_response_body_encoding_encoding_without_content_type' (snip) Finished tests in 672.429322s, 47.6734 tests/s, 9743.0849 assertions/s. 32057 tests, 6551536 assertions, 0 failures, 7 errors, 192 skips ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-freebsd13.4] *** Error code 7 </pre> ### 1. Seven tests in test/net/http/test_http.rb error with "(Connection refused - connect(2) for "localhost" port #####)" These errors appear to be caused by the client in function "fe_request"( **test/net/http/test_http.rb** ) trying to connect to IPv4 ('127.0.0.1') address: <pre> 1324 CONFIG = { * 1325 'host' => 'localhost', 1326 'proxy_host' => nil, 1327 'proxy_port' => nil, 1328 } 1329 1330 include TestNetHTTPUtils 1331 1332 def fe_request(force_enc, content_type=nil) 1333 @server.mount_proc('/fe') do |req, res| 1334 res['Content-Type'] = content_type if content_type 1335 res.body = "hello\u1234" 1336 end 1337 * 1338 http = Net::HTTP.new(config('host'), config('port')) 1339 http.local_host = Addrinfo.tcp(config('host'), config('port')).ip_address 1340 assert_not_nil(http.local_host) 1341 assert_nil(http.local_port) 1342 1343 http.response_body_encoding = force_enc 1344 http.get('/fe') 1345 end </pre> while the @server on line 12 of **test/net/http/utils.rb** listens on a socket with an IPv6 address (':: 1') when tested with ' **localhost** '. <pre> 9 class HTTPServer 10 def initialize(config, &block) 11 @config = config * 12 @server = TCPServer.new(@config['host'], 0) 13 @port = @server.addr[1] 14 @procs = {} </pre> I wasn't sure if this was a bug to fix. As a workaround, remove the following line from /etc/hosts file to eliminate this error: <pre> ::1 localhost ... </pre> ### 2. make test-all stops with "*** Error code 7" after all tests are finished. This is probably a bug in FreeBSD's make command, but it seems to be caused by two spaces at the end of the last command executed when running make test-all: <pre> exec ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems -r./tool/lib/_tmpdir "./test/runner.rb" --ruby="./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems" --excludes-dir=./test/.excludes --name=!/memory_leak/ ←(*here!!) </pre> To fix this error, modify common.mk line 317 or 965 using attachments(one or the other is sufficient) : <pre> % patch < patch-common.mk-TEST_EXCLUDE.txt (or) % patch < patch-common.mk-yes-test-all.txt </pre> Then re-create the Makefile so that "make test-all" completes successfully. <pre> % ./configure % make test-all BASERUBY = /usr/local/bin/ruby --disable=gems CC = clang LD = ld LDSHARED = clang -shared CFLAGS = -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fdeclspec -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wextra-tokens -Wdeprecated-declarations -Wdivision-by-zero -Wdiv-by-zero -Wimplicit-function-declaration -Wimplicit-int -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 -Wmisleading-indentation -Wundef XCFLAGS = -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -fPIE -I. -I.ext/include/x86_64-freebsd13.4 -I./include -I. -I./prism -I./enc/unicode/15.0.0 -Dmodular_gc_dir= CPPFLAGS = DLDFLAGS = -Wl,--compress-debug-sections=zlib -Wl,-soname,showflags -fstack-protector-strong -pie SOLIBS = -lexecinfo -lprocstat -lz -lrt -lrt -ldl -lcrypt -lm -lthr LANG = ja_JP.UTF-8 LC_ALL = LC_CTYPE = MFLAGS = RUSTC = no YJIT_RUSTC_ARGS = --crate-name=yjit --crate-type=staticlib --edition=2021 -g -C lto=thin -C opt-level=3 -C overflow-checks=on '--out-dir=/mnt/home/sakamoto/ruby-3.4.1/yjit/target/release/' ./yjit/src/lib.rs FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git llvmorg-18.1.6-0-g1118c2e05e67) Target: x86_64-unknown-freebsd13.4 Thread model: posix InstalledDir: /usr/bin generating enc.mk generating encdb.h encdb.h unchanged making enc making srcs under enc generating transdb.h transdb.h unchanged making trans making encs generating makefiles ext/configure-ext.mk ext/configure-ext.mk unchanged installing default coverage libraries installing default date_core libraries installing digest libraries installing default digest libraries installing default sha2 libraries installing default fiddle libraries installing default console libraries installing default libraries installing default monitor libraries installing default objspace libraries installing default openssl libraries installing default pathname libraries installing default psych libraries installing default pty libraries installing default ripper libraries installing default libraries installing default socket libraries installing default strscan libraries `ruby' is up to date. Run options: --seed=37281 "--ruby=./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems" --excludes-dir=./test/.excludes --name=!/memory_leak/ -- # Running tests: Finished tests in 669.890724s, 47.8541 tests/s, 9779.2801 assertions/s. 32057 tests, 6551049 assertions, 0 failures, 0 errors, 191 skips ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-freebsd13.4] % </pre> Now "make check" will pass all tests and return "check succeeded" and exit normally (attachment:"ruby34-make-check.txt"). ---Files-------------------------------- patch-common.mk-TEST_EXCLUDE.txt (433 Bytes) patch-common.mk-yes-test-all.txt (373 Bytes) ruby34-make-check.txt (14.7 KB) -- https://bugs.ruby-lang.org/

2 4

[ruby-core:120745] [Ruby master Bug#14582] Unable to use `method__entry` and `method_return` tracing probes since 2.5
by jacobcarlborg (Jacob Carlborg) 20 Jan '25

20 Jan '25

Issue #14582 has been updated by jacobcarlborg (Jacob Carlborg). I'm really interested in using DTrace on Ruby as well. One of the major advantages of DTrace is that it's always available and doesn't require any code changes or restarts of the system that is being instrumented. But with the current way that USDT probes are implemented in Ruby it defeats many of the advantages of DTrace. ---------------------------------------- Bug #14582: Unable to use `method__entry` and `method_return` tracing probes since 2.5 https://bugs.ruby-lang.org/issues/14582#change-111578 * Author: guilhermereiscampos (Guilherme Reis Campos) * Status: Open * ruby -v: 2.5 * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Hi, I am trying to use dtrace/systemtap probes and not being able to use it after the 2.5. The 2.4 version works fine. I was hoping this was fixed on 2.6-preview, but apparently not (just downloaded dev and tested). I tried on OSX using dtrace and also on ubuntu (vagrant). ``` # test.rb class Foo def bar 100.times { "Bar" } end end foo = Foo.new foo.bar # test.stp probe process("/home/vagrant/.rbenv/versions/2.4.0/bin/ruby").mark("method__entry") # you will need to change this to your ruby path of your version. { printf("%s => %s.%s in %s:%d\n", thread_indent(1), kernel_string($arg1),kernel_string($arg2),kernel_string($arg3),$arg4); } probe process("/home/vagrant/.rbenv/versions/2.4.0/bin/ruby").mark("method__return") { printf("%s <= %s.%s in %s:%d\n", thread_indent(-1), kernel_string($arg1),kernel_string($arg2),kernel_string($arg3),$arg4); } ``` dtrace was something similar to it. I was expecting to see this output: ``` # lots of calls # .... # then: 4090 ruby(9667): <= Gem::Specification.unresolved_deps in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/specification.rb:1298 4095 ruby(9667): => MonitorMixin.mon_exit in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:197 4100 ruby(9667): => MonitorMixin.mon_check_owner in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:247 4104 ruby(9667): <= MonitorMixin.mon_check_owner in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:251 4109 ruby(9667): <= MonitorMixin.mon_exit in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:204 4283 ruby(9667): <= Kernel.require in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55 4303 ruby(9667): <= Kernel.require in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55 0 ruby(9667): => Foo.bar in test.rb:3 16 ruby(9667): <= Foo.bar in test.rb:5 ``` (The output above is 2.4) my ruby (all versions that I tested) was install with rb-env: ``` RUBY_CONFIGURE_OPTS='--enable-dtrace --disable-install-doc' rbenv install 2.5.0 ``` I am happy to provide details if required. I'd also be happy to fix it if I have guidance. Thanks, -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120303] [Ruby master Bug#20965] `it` vs `binding.local_variables`
by zverok (Victor Shepelev) 20 Jan '25

20 Jan '25

Issue #20965 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #20965: `it` vs `binding.local_variables` https://bugs.ruby-lang.org/issues/20965 * Author: zverok (Victor Shepelev) * Status: Open * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: DONTNEED ---------------------------------------- `it` is not available in the list of `binding.local_varaibles`, **unlike** numbered parameters: ```ruby p(proc { binding.local_variables }.call) # [] p(proc { |x| binding.local_variables }.call) # [:x] p(proc { _1; binding.local_variables }.call) # [:_1] p(proc { vars = binding.local_variables; _1; vars }.call) # [:_1, :vars] p(proc { it; binding.local_variables }.call) # [] ``` I wonder if it is deliberate or accidental. -- https://bugs.ruby-lang.org/

6 9

[ruby-core:120736] [Ruby master Feature#21047] Change `*nil` to not call `nil.to_a`, for consistency with `**nil`
by jeremyevans0 (Jeremy Evans) 19 Jan '25

19 Jan '25

Issue #21047 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #21047: Change `*nil` to not call `nil.to_a`, for consistency with `**nil` https://bugs.ruby-lang.org/issues/21047 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- In Ruby 3.3, we started accepting `**nil` for keyword splats. This does not call `nil.to_hash`, unlike other uses of `**` for splatting. This made `**nil` handling inconsistent with `*nil` handling, as `*nil` historically has called `nil.to_a`. I propose we make them consistent, by having `*nil` not call `nil.to_a`. Advantage: In addition to more consistent behavior with `**nil`, making `*nil` not call `nil.to_a` opens up new a optimization opportunity, since it allows `*nil` to be optimized to not allocate an array, similar to how `**nil` is already optimized to not allocate a hash. Disadvantage: Minor backwards compatibility breakage, though it is very unlikely any code other than test code will break, because overriding `nil.to_a` to return anything other than the empty array would likely break any large Ruby application. I've submitted a pull request to implement this: https://github.com/ruby/ruby/pull/12597 -- https://bugs.ruby-lang.org/

2 1

[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

[ruby-core:120716] [Ruby master Bug#18613] Voluntary wanted: Some signal-related tests fail on FreeBSD 13
by hs (Hideki Sakamoto) 16 Jan '25

16 Jan '25

Issue #18613 has been updated by hs (Hideki Sakamoto). File patch-test_io_console_test__io__console.rb added File patch-test_ruby_test__thread__queue.rb added File patch-test_ruby_test__thread.rb added I apologize if my comment on the closed ticket is inappropriate. By the way, these bugs seem to have been fixed in FreeBSD 13.4 (or 13.3). I applied the attached patch to the Ruby 3.4.1 source and tried "make test-all" dozens of times in FreeBSD 13.4(while checking #21045), but the error no longer reappeared. <pre> % tar xf ruby-3.4.1.tar.xz % cd ruby-3.4.1/ % patch < patch-test_io_console_test__io__console.rb % patch < patch-test_ruby_test__thread.rb % patch < patch-test_ruby_test__thread__queue.rb % ./configure % make % make test-all </pre> While not a direct reference, a bug report similar to this bug has been reported in FreeBSD Bugzilla – [Bug 277429](https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277429) and appears to have been fixed in 13.3. ---------------------------------------- Bug #18613: Voluntary wanted: Some signal-related tests fail on FreeBSD 13 https://bugs.ruby-lang.org/issues/18613#change-111549 * Author: mame (Yusuke Endoh) * Status: Feedback * Assignee: knu (Akinori MUSHA) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Some tests fail randomly on FreeBSD 13. http://rubyci.s3.amazonaws.com/freebsd13/ruby-master/log/20220216T143001Z.f… ``` 1) Error: TestThread#test_signal_at_join: Timeout::Error: execution of assert_separately expired timeout (120 sec) pid 30743 killed by SIGABRT (signal 6) (core dumped) | /usr/home/chkbuild/chkbuild/tmp/build/20220216T143001Z/ruby/test/ruby/test_thread.rb:1390:in `test_signal_at_join' ``` http://rubyci.s3.amazonaws.com/freebsd13/ruby-master/log/20220308T023001Z.f… ``` 1) Failure: TestThreadQueue#test_thr_kill [/usr/home/chkbuild/chkbuild/tmp/build/20220308T023001Z/ruby/test/ruby/test_thread_queue.rb:175]: only 169/250 done in 60 seconds. ``` http://rubyci.s3.amazonaws.com/freebsd13/ruby-master/log/20220304T163001Z.f… ``` 1) Failure: TestIO_Console#test_intr [/usr/home/chkbuild/chkbuild/tmp/build/20220304T163001Z/ruby/test/io/console/test_io_console.rb:387]: <"25"> expected but was <"-e:12:in `p': \e[1mexecution expired (\e[1;4mTimeout::Error\e[m\e[1m)\e[m">. ``` All of the tests is related to signals. I guess something around signals has changed in FreeBSD 13, but I'm unsure. The failure occurs at high frequency in CI, but rarely does on my FreeBSD shell. We need to investigate what happens. @knu is the platform maintainer for FreeBSD but he is busy. Contribution who is familiar with FreeBSD is welcome. To make it easy to monitor the CI results, I tentatively skipped the three tests on FreeBSD https://github.com/ruby/ruby/commit/17e09f033c4d3b786672ba16d2c5d935482a2fad . If you investigate the issue on FreeBSD, please delete test/excludes/TestThread.rb and test/excludes/TestThreadQueue.rb, and remove the guard in test/io/console/test_io_console.rb. ---Files-------------------------------- patch-test_io_console_test__io__console.rb (508 Bytes) patch-test_ruby_test__thread__queue.rb (276 Bytes) patch-test_ruby_test__thread.rb (337 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120703] [Ruby master Feature#21041] Enum class
by dsisnero (Dominic Sisneros) 15 Jan '25

15 Jan '25

Issue #21041 has been reported by dsisnero (Dominic Sisneros). ---------------------------------------- Feature #21041: Enum class https://bugs.ruby-lang.org/issues/21041 * Author: dsisnero (Dominic Sisneros) * Status: Open ---------------------------------------- Enumerations (Enums) represent a critical abstraction in modern software design, offering significant advantages in type safety, code readability, and system-wide consistency. Most contemporary programming ecosystems—including Java, C#, Python, and Kotlin—provide native enum support, recognizing their fundamental value in representing finite, well-defined sets of values. Beyond basic type definition, enums are increasingly central to interoperability across serialization frameworks. Industry-standard specifications like OpenAPI, Protocol Buffers, and gRPC leverage enums as a canonical way to define constrained value sets, enabling robust code generation and cross-platform compatibility. Implementing a comprehensive Enum class would: - Standardize constant representation - Facilitate seamless code portability - Enable automatic code generation for documentation and client libraries - Enhance type safety and compile-time validation - Improve developer productivity through clear, self-documenting code structures By adopting a robust enum implementation, we can align our development practices with contemporary software engineering principles, reducing complexity and increasing overall system reliability. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120696] [Ruby master Bug#21040] String#next! method does not mutate $& variable
by radarek 15 Jan '25

15 Jan '25

Issue #21040 has been reported by radarek (Radosław Bułat). ---------------------------------------- Bug #21040: String#next! method does not mutate $& variable https://bugs.ruby-lang.org/issues/21040 * Author: radarek (Radosław Bułat) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `String#next!` method should mutate string and return mutated version. For some reason, using it on `$&` does not mutate it but still returns new version. Steps to reproduce (2 different ways): ```ruby "123".gsub(/./){$&.next!} # returns "234" as expected "123".gsub(/./){$&.next!;$&} # returns "123" but should be "234" "123".gsub(/./){_1.next!;_1} # returns "234" as expected "123"[/./] puts $&. # prints 1 puts $&.next! # prints 2 puts $& # prints 1 but should be 2 ``` -- https://bugs.ruby-lang.org/

3 2