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

[ruby-core:124355] [Ruby Feature#6012] Proc#source_location also return the column
by matz (Yukihiro Matsumoto) 24 Dec '25

24 Dec '25

Issue #6012 has been updated by matz (Yukihiro Matsumoto). I didn't mean to cancel nor reject this proposal. It would probably be merged in 4.1 (or later). But since any design mistake would remain virtually forever in Ruby, and I am the one to be blamed. We had some concerns, e.g. #21783 or #21784 and it was only days before the release. Matz. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-115866 * Author: rogerdpack (Roger Pack) * Status: Open * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124351] [Ruby Bug#21802] segmentation fault when installing gems on CI
by luizkowalski (Luiz Kowalski) 23 Dec '25

23 Dec '25

Issue #21802 has been reported by luizkowalski (Luiz Kowalski). ---------------------------------------- Bug #21802: segmentation fault when installing gems on CI https://bugs.ruby-lang.org/issues/21802 * Author: luizkowalski (Luiz Kowalski) * Status: Open * ruby -v: ruby 3.4.8 (2025-12-17 revision 995b59f666) +YJIT +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- hey! recently, we updated to Bundler v4 (currently running v4.0.3) and Ruby 3.4.8. Since then, one of our CircleCI steps has been failing repeatedly, often without logs. Sometimes it does fail with a log ``` Installing faraday-typhoeus 1.1.0 Fetching http 5.3.1 /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:369: [BUG] Segmentation fault at 0x00007f336df8c100 ruby 3.4.8 (2025-12-17 revision 995b59f666) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0026 p:---- s:0142 e:000141 CFUNC :each_value c:0025 p:0078 s:0138 e:000137 METHOD /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:369 c:0024 p:0030 s:0131 e:000130 METHOD /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:678 c:0023 p:0005 s:0125 e:000124 BLOCK /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:697 c:0022 p:0053 s:0121 e:000120 METHOD /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package/tar_reader.rb:67 c:0021 p:0005 s:0114 e:000113 METHOD /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:696 c:0020 p:0011 s:0108 e:000107 BLOCK /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:626 c:0019 p:0020 s:0104 e:000103 METHOD /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package/tar_reader.rb:25 c:0018 p:0007 s:0098 e:000097 BLOCK /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:623 [FINISH] c:0017 p:---- s:0094 e:000093 CFUNC :open c:0016 p:0013 s:0088 e:000087 METHOD /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package/file_source.rb:30 c:0015 p:0015 s:0083 e:000082 METHOD /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:622 c:0014 p:0008 s:0078 e:000077 METHOD /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:603 c:0013 p:0005 s:0074 e:000073 METHOD /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/installer.rb:254 c:0012 p:0020 s:0070 e:000069 METHOD /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/rubygems_gem_installer.rb:140 c:0011 p:0196 s:0066 e:000065 METHOD /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/source/rubygems.rb:195 c:0010 p:0025 s:0052 e:000051 METHOD /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/installer/gem_installer.rb:54 c:0009 p:0003 s:0048 e:000047 METHOD /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/installer/gem_installer.rb:17 c:0008 p:0037 s:0042 e:000041 METHOD /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/installer/parallel_installer.rb:133 c:0007 p:0007 s:0033 e:000032 BLOCK /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/installer/parallel_installer.rb:124 c:0006 p:0009 s:0028 e:000027 METHOD /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/worker.rb:62 c:0005 p:0030 s:0021 e:000019 BLOCK /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/worker.rb:57 c:0004 p:0017 s:0016 e:000015 METHOD <internal:kernel>:168 c:0003 p:0004 s:0011 e:000010 METHOD /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/worker.rb:54 c:0002 p:0005 s:0006 e:000005 BLOCK /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/worker.rb:90 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/worker.rb:90:in 'block (2 levels) in create_threads' /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/worker.rb:54:in 'process_queue' <internal:kernel>:168:in 'loop' /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/worker.rb:57:in 'block in process_queue' /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/worker.rb:62:in 'apply_func' /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/installer/parallel_installer.rb:124:in 'block in worker_pool' /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/installer/parallel_installer.rb:133:in 'do_install' /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/installer/gem_installer.rb:17:in 'install_from_spec' /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/installer/gem_installer.rb:54:in 'install' /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/source/rubygems.rb:195:in 'install' /home/circleci/.rubygems/gems/bundler-4.0.2/lib/bundler/rubygems_gem_installer.rb:140:in 'spec' /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/installer.rb:254:in 'spec' /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:603:in 'spec' /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:622:in 'verify' /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package/file_source.rb:30:in 'with_read_io' /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package/file_source.rb:30:in 'open' /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:623:in 'block in verify' /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package/tar_reader.rb:25:in 'new' /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:626:in 'block (2 levels) in verify' /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:696:in 'verify_files' /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package/tar_reader.rb:67:in 'each' /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:697:in 'block in verify_files' /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:678:in 'verify_entry' /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:369:in 'digest' /usr/*****/lib/ruby/site_ruby/3.4.0/rubygems/package.rb:369:in 'each_value' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 44 -- Machine register context ------------------------------------------------ RIP: 0x00007f336df8bffe RBP: 0x00007f333dd38270 RSP: 0x00007f333dd38190 RAX: 0x00007f336df8c100 RBX: 0x000055fb7a768350 RCX: 0x000055fb7956d330 RDX: 0x0000000000000000 RDI: 0x00007f336e501740 RSI: 0x0000000000000000 R8: 0x0000000000000003 R9: 0x000055fb7fd9ab78 R10: 0x0000000055550083 R11: 0x000055fb7fe9a1c1 R12: 0x00007f328c55e568 R13: 0x00007f328c55e568 R14: 0x000055fb7fe9a1a8 R15: 0x0000000000000000 EFL: 0x0000000000010202 -- C level backtrace information ------------------------------------------- /bin/bash: line 5: 1060 Killed bundle install ``` while trying to find the root cause, I noticed that **rolling back to Ruby 3.4.7 solves the issue** . there's not a lot going on with the CI step, too: ```yaml verify-contract: docker: - image: cimg/ruby:3.4.8-node environment: RAILS_ENV: test MYSQL_HOST: 127.0.0.1 MYSQL_STATSDB_HOST: 127.0.0.1 CONTRACT_URL: << pipeline.parameters.contract_url >> CONSUMER_NAME: << pipeline.parameters.consumer_name >> CONSUMER_VERSION: << pipeline.parameters.consumer_version >> PROVIDER_VERSION: << pipeline.parameters.provider_version >> PUBLISH_VERIFICATION_RESULTS: true DYNAMODB_AWS_REGION: us-east-1 DYNAMODB_AWS_ACCESS_KEY_ID: local DYNAMODB_AWS_SECRET_ACCESS_KEY: local DYNAMODB_AWS_ENDPOINT: http://dynamodb:8000 - image: cimg/mysql:8.0.42 environment: MYSQL_ALLOW_EMPTY_PASSWORD: 1 - image: cimg/redis:8.4.0 - image: amazon/dynamodb-local:latest name: dynamodb command: ["-jar", "DynamoDBLocal.jar", "-sharedDb"] steps: - checkout - vault/get-secrets: template-preset: "ruby-gem-read" - run: name: Install bundler command: | gem install bundler - run: name: Ruby Environment Information command: | gem env bundle config - run: name: Install deps and verify contracts command: | if [ ! -z "${PROVIDER_VERSION}" ]; then git checkout ${PROVIDER_VERSION} fi bundle config https://rubygems.pkg.github.com/xxxxx "${RUBYGEMS_USER}:${RUBYGEMS_PASSWORD}" bundle install bundle clean --force bundle exec rake database:recreate_all if [[ -z "$CONTRACT_URL" ]]; then bundle exec rake pact:verify else bundle exec rake pact:verify:at[$CONTRACT_URL] || true fi ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124340] [Ruby Bug#21799] Delegated top-level methods are not visible outside the Ruby Box
by koic (Koichi ITO) 23 Dec '25

23 Dec '25

Issue #21799 has been reported by koic (Koichi ITO). ---------------------------------------- Bug #21799: Delegated top-level methods are not visible outside the Ruby Box https://bugs.ruby-lang.org/issues/21799 * Author: koic (Koichi ITO) * Status: Open * ruby -v: ruby 4.0.0dev (2025-12-21T19:08:00Z master cfb324e9d1) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following example code based on Ruby Box results in an unexpected error. https://github.com/ruby/ruby/blob/v4.0.0-preview3/doc/language/box.md#top-l… I'm not familiar with Ruby Box, but it seems that either the above documentation example in doc/language/box.md or the Ruby Box implementation is incorrect. ## Steps to reproduce ```console $ cat main.rb box = Ruby::Box.new box.require_relative('foo') p box.Foo.say #=> "foo" p yay # NoMethodError ``` ```console $ cat foo.rb def yay = "foo" class Foo def self.say = yay end p Foo.say #=> "foo" p yay #=> "foo" ``` ## Expected According to the documentation example, `box.Foo.say` in `main.rb` should return the string `"foo"`. ## Actual Contrary to the documentation example, calling `box.Foo.say` in `main.rb` raises a `NoMethodError`. ```console $ RUBY_BOX=1 ruby main.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/language/box.md for known issues, etc. "foo" "foo" main.rb:4:in '<main>': undefined method 'Foo' for module #<Ruby::Box:3,user,optional> (NoMethodError) p box.Foo.say #=> "foo" ^^^^ ``` ## Additional Information According to the description below, the documentation example might not be appropriate, but it's unclear what visibility delegated top-level methods have. > Currently, top level methods in boxes are not accessible from outside of the box. But there might be a use case to call other box's top level methods. https://github.com/ruby/ruby/blob/v4.0.0-preview3/doc/language/box.md#expos… -- https://bugs.ruby-lang.org/

3 2

[ruby-core:124343] [Ruby Feature#17001] [Feature] Dir.scan to yield dirent for efficient and composable recursive directory scaning
by byroot (Jean Boussier) 22 Dec '25

22 Dec '25

Issue #17001 has been updated by byroot (Jean Boussier). Status changed from Open to Closed Closing in favor of [Feature #21800] ---------------------------------------- Feature #17001: [Feature] Dir.scan to yield dirent for efficient and composable recursive directory scaning https://bugs.ruby-lang.org/issues/17001#change-115849 * Author: byroot (Jean Boussier) * Status: Closed ---------------------------------------- ### Use case When you need to recusrsively scan a directory, you either have to use `Dir[]` / `Dir.glob`, which is fine for small directories or simple patterns, but can easily take several seconds to complete for large repositories or complex patterns and returns a very large array which tend to trash GC. Or you can use `Dir.each_entry` / `Dir.foreach` recursively, but then you need to `stat` each entry to know wether it's a directory, or even symlink if you want to follow them. This means one syscall per directory, and one per file and directories. This is particularly impactful on OSX where `stat()` is several times slower than on Linux because of various sandboxing features. There's a [typical example of this use case in Bootsnap](https://github.com/Shopify/bootsnap/blob/56c61373000573112ee027da…. ### Proposal [Python introduced `os.scandir` a few years ago](https://www.python.org/dev/peps/pep-0471/) for exactly this purpose. It is functionaly similar to `Dir.foreach` / `Dir.each_child`, except it yields `DirEntry` instances which are a wrapper around the `libc` `dirent` struct. I reduced the Bootsnap code into a [simplified benchmark](https://gist.github.com/casperisfine/2124f349c6564560df4399f2ead…, and using `os.scandir()` Python scan our main repo in a bit over `1s`, which 3 to 4 times faster than Ruby can with `Dir.foreach` (`3-4s`). For comparison sake `Dir['**/*.rb']` also complete in about `1s`. So I beleive that exposing a similar `Dir.scan` method, returning `Dir::Entry` instances, with methods inspired from `File::Stat` such as `directory?` would allow for more performant file system scaning when the query is not easily expressed with a glob pattern. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124292] [Ruby Bug#21792] 4.0.0-preview2: Build fails with `--with-ext=` when ENABLE_SHARED=yes: ruby/digest.h not found for rubyspec CAPI extensions
by mdalessio (Mike Dalessio) 20 Dec '25

20 Dec '25

Issue #21792 has been reported by mdalessio (Mike Dalessio). ---------------------------------------- Bug #21792: 4.0.0-preview2: Build fails with `--with-ext=` when ENABLE_SHARED=yes: ruby/digest.h not found for rubyspec CAPI extensions https://bugs.ruby-lang.org/issues/21792 * Author: mdalessio (Mike Dalessio) * Status: Open * Target version: 4.0 ---------------------------------------- When building Ruby with `--enable-shared` and `--with-ext=` (empty, to disable all extensions), the build fails because spec/ruby/optional/capi/ext/digest_spec.c cannot find ruby/digest.h. This affects cross-compilation tooling like `rake-compiler` which uses these configure options to build a minimal Ruby for cross-compiling native gems. ## Reproducing Download and extract ruby-4.0.0-preview2 source code. ``` cd ruby-4.0.0-preview2 ./configure --enable-shared --disable-install-doc --with-ext= make ``` Or alternatively, use rake-compiler: ``` mkdir ~/.rake-compiler rake-compiler cross-ruby VERSION=4.0.0-preview2 HOST=x86_64-linux-gnu ``` Either way, you will see: ``` spec/ruby/optional/capi/ext/digest_spec.c:4:10: fatal error: ruby/digest.h: No such file or directory 4 | #include "ruby/digest.h" | ^~~~~~~~~~~~~~~ compilation terminated. make: *** [defs/gmake.mk:521: spec/ruby/optional/capi/ext/digest_spec.so] Error 1 ``` ## Root Cause I believe the root cause is: 1. defs/gmake.mk:531-532 unconditionally adds rubyspec-capiext to the exts target when ENABLE_SHARED=yes: ``` ifeq ($(ENABLE_SHARED),yes) exts: rubyspec-capiext endif ``` 2. rubyspec-capiext builds all *.c files in spec/ruby/optional/capi/ext/, including digest_spec.c 3. digest_spec.c (line 4) includes ruby/digest.h 4. ruby/digest.h is only installed when the digest extension is built. From ext/digest/extconf.rb:7-9: ``` $INSTALLFILES = { "digest.h" => "$(HDRDIR)" } if $extmk ``` 5. With --with-ext= (empty), the digest extension is not built, so digest.h is never copied to .ext/include/ruby/ 6. The build fails because digest_spec.c requires a header that was never installed Note that before 269ad29d, no rubyspec CAPI extension required extension-specific headers, so this configuration worked. -- https://bugs.ruby-lang.org/

3 7

[ruby-core:124051] [Ruby Feature#21767] Consider procs which `self` is Ractor-shareable as Ractor shareable
by osyoyu (Daisuke Aritomo) 20 Dec '25

20 Dec '25

Issue #21767 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Feature #21767: Consider procs which `self` is Ractor-shareable as Ractor shareable https://bugs.ruby-lang.org/issues/21767 * Author: osyoyu (Daisuke Aritomo) * Status: Open ---------------------------------------- I would like to allow procs which `self` is Ractor-shareable to be automatically eligible as shareable, without an explicit `Ractor.make_shareable` call. ```ruby class C PROC = proc { p ARRAY }.freeze end Ractor.new { C::PROC.call }.value # Allow this, since `C` is shareable ``` Proposal is: Consider procs/lambdas which meet the following condition as Ractor-shareable. - The proc is frozen. - The proc's `self` is shareable. This proposal is has taken inspiration from #21033 . ## Usecase The main usecase in mind is procs/lambdas in class-level constants. Some libraries store procs in constants as a convenient place for library-wide logic. Those procs usually do not access unshareable state, thus conceptually safe to be shared across Ractors. However, the current limitation completely blocks this. Examples may be found in ruby/ruby, and I have submitted a pull request to migrate one to `Ractor.shareable_proc`. ```ruby class Pathname SAME_PATHS = if File::FNM_SYSCASE.nonzero? # Avoid #zero? here because #casecmp can return nil. proc {|a, b| a.casecmp(b) == 0} else proc {|a, b| a == b} end end ``` https://github.com/search?q=repo%3Aruby%2Fruby%20%2F(%3F-i)%5BA-Z%5D%20%3D%… More examples can be found in public code. https://github.com/search?q=language%3Aruby+%2F%28%3F-i%29%5BA-Z%5D+%3D+%28… It can be observed that a good portion of these do not access unshareable state. Appending `.freeze` would be much more acceptable than redefining using `Ractor.shareable_proc`, which is a Ruby 4.0-only feature. ## Discussion: Change of behavior when illegal access occurs in proc Consider this code. The proc accesses non-frozen `C::ARRAY`, which is against the rules of Ractors regardless of this patch. ```ruby class C ARRAY = [] PROC = proc { p ARRAY } end # Still illegal since C::ARRAY is not shareable Ractor.new { C::PROC.call }.value ``` This code used to raise on `C::PROC.call` (`can not access non-shareable objects in constant C::PROC by non-main Ractor.`). When this patch is applied, it will raise on `p ARRAY` (`can not access non-shareable objects in constant C::ARRAY by non-main ractor.`). This could be debatable change. If this is not acceptable, I'd like to revisit #21033 . -- https://bugs.ruby-lang.org/

3 4

[ruby-core:121642] [Ruby Bug#21266] YJIT GC safety crash with proc objects as block argument
by alanwu (Alan Wu) 19 Dec '25

19 Dec '25

Issue #21266 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #21266: YJIT GC safety crash with proc objects as block argument https://bugs.ruby-lang.org/issues/21266 * Author: alanwu (Alan Wu) * Status: Open * Assignee: yjit * Backport: 3.2: DONTNEED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- ```ruby # Run with --yjit-call-threshold=1 def foo(args) = bar(*args, &proc { _1 }) def bar(_, _, _, _, *rest) = yield rest GC.stress = true foo([1,2,3,4]) foo([1,2,3,4]) ``` The proc in these calls get collected on the yield to the GC to allocate the rest parameter arary. ``` ../vm_core.h:1668: Assertion Failed: vm_block_handler_type:rb_obj_is_proc(block_handler) ``` Or in release builds: ``` ../test.rb:1: [BUG] Segmentation fault at 0x0000000000000020 ruby 3.3.6 (2024-11-05 revision 75015d4c1f) +YJIT [arm64-darwin24] -- C level backtrace information ------------------------------------------- /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_vm_bugreport+0xb4c) [0x104595590] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_bug_for_fatal_signal+0x100) [0x1043d6120] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(sig_do_nothing+0x0) [0x1044fc4b0] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x187572de4] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_vm_invokeblock+0x144) [0x10456b004] ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:124307] [Ruby Bug#21794] O_CLOEXEC is not available on Solaris 10
by ngoto (Naohisa Goto) 19 Dec '25

19 Dec '25

Issue #21794 has been reported by ngoto (Naohisa Goto). ---------------------------------------- Bug #21794: O_CLOEXEC is not available on Solaris 10 https://bugs.ruby-lang.org/issues/21794 * Author: ngoto (Naohisa Goto) * Status: Open * ruby -v: ruby 4.0.0dev (2025-12-18T07:47:43Z master 9f266ae674) +PRISM [sparc64-solaris2.10] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Because O_CLOEXEC is not available on Solaris 10, an error occurs when compiling box.c: "'O_CLOEXEC' undeclared (first use in this function)" ``` gcc -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wdeprecated-declarations -Wdiv-by-zero -Wduplicated-cond -Wimplicit-function-declaration -Wimplicit-int -Wpointer-arith -Wwrite-strings -Wold-style-definition -Wimplicit-fallthrough=0 -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-packed-bitfield-compat -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wunused-variable -Wmisleading-indentation -Wundef -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -fPIE -I. -I.ext/include/sparc64-solaris2.10 -I.ext/include -I../ruby.devel.ORIG/include -I../ruby.devel.ORIG -I../ruby.devel.ORIG/prism -I../ruby.devel.ORIG/enc/unicode/17.0.0 -Dmodular_gc_dir="" -D_XOPEN_SOURCE=600 -I/usr/local/64/lib/libffi-3.0.10/include -I/usr/local/64/include -o box.o -c ../ruby.devel.ORIG/box.c ../ruby.devel.ORIG/box.c: In function 'copy_ext_file': ../ruby.devel.ORIG/box.c:634:63: error: 'O_CLOEXEC' undeclared (first use in this function); did you mean 'FD_CLOEXEC'? const int dst_fd = open(dst_path, O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC|bin, S_IRWXU); ^~~~~~~~~ FD_CLOEXEC ../ruby.devel.ORIG/box.c:634:63: note: each undeclared identifier is reported only once for each function it appears in ../ruby.devel.ORIG/box.c: At top level: cc1: warning: unrecognized command line option '-Wno-self-assign' cc1: warning: unrecognized command line option '-Wno-parentheses-equality' cc1: warning: unrecognized command line option '-Wno-constant-logical-operand' cc1: warning: unrecognized command line option '-Wno-cast-function-type' make: *** [box.o] Error 1 ``` The following quick patch resolved the error. ``` diff --git a/box.c b/box.c index 14f6acdd82..120bef3d3d 100644 --- a/box.c +++ b/box.c @@ -631,7 +631,25 @@ copy_ext_file(const char *src_path, const char *dst_path) return COPY_ERROR_SRC_STAT; } +#ifdef O_CLOEXEC const int dst_fd = open(dst_path, O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC|bin, S_IRWXU); +#else + int tmp_dst_fd = open(dst_path, O_WRONLY|O_CREAT|O_EXCL|bin, S_IRWXU); + do { + int dst_fd_flags; + if (tmp_dst_fd < 0) break; + dst_fd_flags = fcntl(tmp_dst_fd, F_GETFD, 0); + if (dst_fd_flags > 0) { + dst_fd_flags |= FD_CLOEXEC; + if (fcntl(tmp_dst_fd, F_SETFD, dst_fd_flags) == 0) break; + /* error */ + close(tmp_dst_fd); + tmp_dst_fd = -1; + break; + } + } while(0); + const int dst_fd = tmp_dst_fd; +#endif if (dst_fd < 0) { close(src_fd); return COPY_ERROR_DST_OPEN; ``` Note that Solaris 11 has O_CLOEXEC. If someone argues that we no longer need to support older operating systems that lack O_CLOEXEC, I find it very difficult to counter that argument. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123845] [Ruby Bug#21696] Performance degradation for long running processes in Ruby 4.0.0-preview2
by easydwh (Ivo Herweijer) 19 Dec '25

19 Dec '25

Issue #21696 has been reported by easydwh (Ivo Herweijer). ---------------------------------------- Bug #21696: Performance degradation for long running processes in Ruby 4.0.0-preview2 https://bugs.ruby-lang.org/issues/21696 * Author: easydwh (Ivo Herweijer) * Status: Open * ruby -v: ruby 4.0.0preview2 (2025-11-17 master 4fa6e9938c) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When running my RubyMeasureResponsetime tool (https://github.com/easydatawarehousing/ruby_measure_responsetime) on Ruby 4.0.0-preview2, a slow but steady performance degradation is measurable. Both the Rails and the Roda based test applications show this. And both with and without yjit. The Rails application when using yjit also seems to have increasing memory usage over time. Running the same tests on Ruby 3.4.7 shows stable performance and memory usage. I have included some plots showing this behavior. ---Files-------------------------------- rails_devise_2_ruby-4.0.0.jpg (965 KB) rodauth_2_ruby-4.0.0 YJIT.jpg (973 KB) rodauth_2_ruby-4.0.0.jpg (1.02 MB) rails_devise_2_ruby-4.0.0 YJIT.jpg (917 KB) rails_devise_0_memory.png (31.2 KB) -- https://bugs.ruby-lang.org/

3 5

[ruby-core:124289] [Ruby Feature#21791] Implement Set#compact/Set#compact!, these should return Set instead of Array
by herwin (Herwin W) 19 Dec '25

19 Dec '25

Issue #21791 has been reported by herwin (Herwin W). ---------------------------------------- Feature #21791: Implement Set#compact/Set#compact!, these should return Set instead of Array https://bugs.ruby-lang.org/issues/21791 * Author: herwin (Herwin W) * Status: Open ---------------------------------------- I recently had to remove a nil value from a Set, and ended up with an Array: ``` irb(main):001> Set[1, 2, nil, 3].compact => [1, 2, 3] irb(main):002> Set[1, 2, nil, 3].compact.class => Array ``` Since there is no dedicated `Set#compact`, this is done via `Enumerable#compact` and this results in an Array. To preserve the Set, the following works: ```ruby set - [nil] # compact set.delete_if(&:nil?) # compact! set.compact.to_set # compact, but slow ``` Both are rather ugly. This patch implements `Set#compact` and `Set#compact!` in a way that preserves the class. There are probably more methods that could have their own implementation, for example `Set#select`/`Set#reject` now returns arrays too (but `Set#select!` and `Set#reject!` work as expected. Pull request: https://github.com/ruby/ruby/pull/15614 -- https://bugs.ruby-lang.org/

2 2