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

[ruby-core:122643] [Ruby Bug#21498] Windows - Ruby Overrides C Library APIs thus breaking them
by cfis (Charlie Savage) 25 Nov '25

25 Nov '25

Issue #21498 has been reported by cfis (Charlie Savage). ---------------------------------------- Bug #21498: Windows - Ruby Overrides C Library APIs thus breaking them https://bugs.ruby-lang.org/issues/21498 * Author: cfis (Charlie Savage) * Status: Open * ruby -v: *all* on windows (testing with ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x64-mswin64_140]) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I am trying to wrap a simple C++ library, https://github.com/baderouaich/BitmapPlusPlus, as a Ruby extension. However when I use the extension to write a bitmap to disk the bitmap is corrupted. This is because the library uses std::ofstream which eventually uses the C API fclose to write the final bytes to the bitmap file and then closes it. The problem is that Ruby overrides `fclose` and replaces it with `rb_w32_fclose`. It then *exports* its custom version from from x64-vcruntime140-ruby340.dll. And the exported version is broken (at least from the standpoint of the C standard library). Note this has been a long standing issue. The first report I see is from 2013: https://bugs.ruby-lang.org/issues/8569 More recently in 2020 (which explains the issue very well): https://github.com/NREL/OpenStudio/issues/3942#issuecomment-610673401 I understand that Ruby is trying to provide a platform independent API. But the problem is this solution breaks any third party libraries that rely on these C APIs (which of course are very common). And there is no good workaround (see https://github.com/NREL/OpenStudio/issues/3942#issuecomment-611072774) So would it be possible for Ruby to stop exporting custom versions of basic C APIs? The code that does it is here: https://github.com/ruby/ruby/blob/master/win32/mkexports.rb#L41 Ruby of course could still use its custom versions of fclose, read, write etc within ruby.exe and x64-vcruntime140-ruby340.dll. But they should not be exported from x64-vcruntime140-ruby340.dll and thus be off limits to extensions. If a case comes up where an extension really needs access to rb_w32_fclose instead of fclose then an extension developer can use an `#ifdef _WIN32` to do so and work across platforms. That at least puts the developer in control versus now where I don't see any way I can to wrap the bitmap library for usage in Ruby. From my experience the biggest problem is the replacing of fclose with rb_w32_fclose. But I propose removing all such mappings, which include: FD_CLR=rb_w32_fdclr FD_ISSET=rb_w32_fdisset Sleep=rb_w32_Sleep accept=rb_w32_accept access=rb_w32_uaccess bind=rb_w32_bind close=rb_w32_close connect=rb_w32_connect dup2=rb_w32_dup2 fclose=rb_w32_fclose fstat=rb_w32_fstati128 get_osfhandle=rb_w32_get_osfhandle getcwd=rb_w32_ugetcwd getenv=rb_w32_ugetenv gethostbyaddr=rb_w32_gethostbyaddr gethostbyname=rb_w32_gethostbyname gethostname=rb_w32_gethostname getpeername=rb_w32_getpeername getpid=rb_w32_getpid getppid=rb_w32_getppid getprotobyname=rb_w32_getprotobyname getprotobynumber=rb_w32_getprotobynumber getservbyname=rb_w32_getservbyname getservbyport=rb_w32_getservbyport getsockname=rb_w32_getsockname getsockopt=rb_w32_getsockopt inet_ntop=rb_w32_inet_ntop inet_pton=rb_w32_inet_pton ioctlsocket=rb_w32_ioctlsocket isatty=rb_w32_isatty listen=rb_w32_listen lseek=rb_w32_lseek lstat=rb_w32_ulstati128 mkdir=rb_w32_umkdir mmap=rb_w32_mmap mprotect=rb_w32_mprotect munmap=rb_w32_munmap pipe=rb_w32_pipe pread=rb_w32_pread pwrite=rb_w32_pwrite read=rb_w32_read recv=rb_w32_recv recvfrom=rb_w32_recvfrom rename=rb_w32_urename rmdir=rb_w32_urmdir select=rb_w32_select send=rb_w32_send sendmsg sendto=rb_w32_sendto setsockopt=rb_w32_setsockopt shutdown=rb_w32_shutdown socket=rb_w32_socket stati128=rb_w32_ustati128 strcasecmp=msvcrt.stricmp strerror=rb_w32_strerror strncasecmp=msvcrt.strnicmp times=rb_w32_times unlink=rb_w32_uunlink utime=rb_w32_uutime utimensat=rb_w32_uutimensat utimes=rb_w32_uutimes write=rb_w32_write -- https://bugs.ruby-lang.org/

6 32

[ruby-core:123890] [Ruby Bug#21708] Ruby 3.4 Forwardable: setter delegations trigger SyntaxError from forwardable/impl.rb
by jfi (James Inman) 24 Nov '25

24 Nov '25

Issue #21708 has been reported by jfi (James Inman). ---------------------------------------- Bug #21708: Ruby 3.4 Forwardable: setter delegations trigger SyntaxError from forwardable/impl.rb https://bugs.ruby-lang.org/issues/21708 * Author: jfi (James Inman) * Status: Open * ruby -v: 3.4.7 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- - `forwardable`: 1.3.3 (bundled stdlib) - OS: Ubuntu 24.04 (also reproducible on macOS) - RUBYOPT / $DEBUG: default (but with $DEBUG=true or RUBYOPT=-d the errors are emitted) # Reproduction Script (minimal) ``` require "forwardable" class Host attr_accessor :scheme end class Delegator extend Forwardable def initialize @host = Host.new end def_delegator :@host, :scheme=, :scheme= def_delegator :@host, :scheme, :scheme end $DEBUG = true # force forwardable to log the SyntaxError d = Delegator.new d.scheme = "https" puts d.scheme ``` Output running with `ruby -d`: ``` Exception 'SyntaxError' at .../forwardable/impl.rb:6 - syntax errors found > 6 | BEGIN{throw tag}; ().scheme= | ^ expected an expression after `=` ``` Despite the `SyntaxError`, the program continues, but stderr is flooded whenever a setter is delegated. Similar errors appear for any delegated setter (`host=`, `port=`, etc.), causing noise in test runs and CI logs. # Expected behavior Delegating setter methods should not raise or log `SyntaxError`; `forwardable` should generate the delegator quietly, as in Ruby 3.3 and earlier. # Other reports - ruby/forwardable issue #35 shows the same SyntaxError output pattern on Ruby 3.4: https://github.com/ruby/forwardable/issues/35 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123888] [Ruby Feature#21706] Add SIMD optimizations for string comparison operations
by sebyx07 (Sebastian Buza) 23 Nov '25

23 Nov '25

Issue #21706 has been reported by sebyx07 (Sebastian Buza). ---------------------------------------- Feature #21706: Add SIMD optimizations for string comparison operations https://bugs.ruby-lang.org/issues/21706 * Author: sebyx07 (Sebastian Buza) * Status: Open ---------------------------------------- # Feature: SIMD-accelerated String Comparison (SSE2/NEON) **PR:** https://github.com/ruby/ruby/pull/15307 ## Summary SIMD optimizations for string comparison using SSE2 (x86_64) and NEON (ARM64). **17.2% average speedup** for strings e16 bytes, zero API changes, automatic fallback. - Backward compatible, all tests pass - Cross-platform (SSE2/NEON/memcmp fallback) - 1 new file (~400 lines), 2 files modified (5 lines total) ## Benchmark Results **Platform:** AMD EPYC 7282 16-Core, 47GB RAM, Ubuntu 24.04.3 LTS **Method:** Side-by-side master vs SIMD (5M iterations, default build) | Size | Operation | Master | SIMD | � | |------|-----------|--------|------|---| | 16B | `String#==` | 14.2M/s | 17.5M/s | **+23.3%** | | 16B | `String#eql?` | 11.1M/s | 14.8M/s | **+33.1%** | | 16B | `String#<=>` | 10.8M/s | 13.4M/s | **+23.8%** | | 64B | `String#==` | 14.0M/s | 16.4M/s | **+17.8%** | | 64B | `String#<=>` | 11.2M/s | 13.3M/s | **+18.5%** | | 256B | `String#==` | 14.0M/s | 15.2M/s | **+8.7%** | | 1KB | `String#==` | 12.5M/s | 14.9M/s | **+19.3%** | | 4KB | `String#==` | 9.0M/s | 10.4M/s | **+15.4%** | **Average:** +17.2% (range: +8.7% to +33.1%) ## Implementation ### Files Changed **`internal/string_simd.h`** (new, ~400 lines) - `rb_str_simd_memcmp(ptr1, ptr2, len)` - returns -1/0/+1 - `rb_str_simd_memeq(ptr1, ptr2, len)` - returns 0/1 - SSE2: `_mm_loadu_si128`, `_mm_cmpeq_epi8`, `_mm_movemask_epi8` - NEON: `vld1q_u8`, `vceqq_u8`, `vminvq_u8` - Threshold: 16-256 bytes (SIMD active), else memcmp - CPU detection: `__builtin_cpu_supports("sse2")` / ARM macros **`internal/string.h`** (2 lines) ```c #include "internal/string_simd.h" // rb_str_eql_internal: memcmp() � rb_str_simd_memeq() ``` **`string.c`** (3 lines) ```c #include "internal/string_simd.h" // rb_str_cmp: memcmp() � rb_str_simd_memcmp() // fstring_concurrent_set_cmp: memcmp() � rb_str_simd_memeq() ``` ### Optimized Functions (5 total) 1. `rb_str_cmp()` - `String#<=>`, sort 2. `rb_str_eql_internal()` - `String#==`, `#eql?` 3. `fstring_concurrent_set_cmp()` - frozen string dedup 4. `deleted_prefix_length()` - `String#start_with?`, `#delete_prefix` 5. `deleted_suffix_length()` - `String#end_with?`, `#delete_suffix` ### Technical Details **SSE2 (x86_64):** Processes 16 bytes/iteration, unrolled to 32 bytes in equality checks. Uses `__builtin_ctz()` for first-difference detection, `__restrict__` pointers, `LIKELY`/`UNLIKELY` branch hints. **NEON (ARM64):** 16 bytes/iteration using `uint8x16_t` vectors, horizontal min for difference detection. **Thresholds:** - `< 16 bytes` � standard memcmp (setup overhead) - `16-256 bytes` � SIMD - `> 256 bytes` � memcmp (cache effects dominate) **Type safety:** All pointers cast to `unsigned char*` (prevents signed comparison UB). ## Platform Support | Platform | Implementation | Fallback | |----------|----------------|----------| | x86_64 | SSE2 (universal since 2003) | memcmp | | ARM64 | NEON | memcmp | | Others | - | memcmp | Runtime detection, no special build flags required. ## Testing ```bash # Functional (all existing tests pass) make test-all # Performance ./ruby benchmark/string_comparison_simple.rb # Verify SSE2 instructions objdump -d ruby | grep -A5 "rb_str_cmp" | grep -E "movdqu|pcmpeqb|pmovmskb" ``` ## Design Rationale 1. **Pattern follows `ext/json/simd/simd.h`** - familiar to contributors 2. **Conservative start** - SSE2/NEON (universal), AVX2 is trivial add later 3. **unsigned char*** - matches memcmp semantics, prevents UB 4. **Inline + hot attributes** - compiler optimization hints 5. **Zero breaking changes** - drop-in memcmp replacement ## Future Extensions **Phase 2 (easy):** - AVX2: 32 bytes/iter (~50 LOC, `__builtin_cpu_supports("avx2")`) - `String#index`/`#rindex`: SIMD substring search - `String#casecmp`: case-insensitive SIMD **Phase 3 (advanced):** - UTF-8 validation, `upcase`/`downcase` transforms - SSE4.2 `pcmpistri` for substring search - POPCNT for `Integer#bit_count` ## Impact String comparison is in every Ruby program (hash lookups, routing, JSON, ORMs). This proves SIMD integration works and establishes pattern for future optimizations. **Real-world:** Rails apps, JSON APIs see 10-25% string operation speedup. **Prior art:** V8, Go, Rust, glibc, musl all use SIMD for string ops. --- **Developed with:** Claude Code (AI-assisted, ~3 hours) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122296] [Ruby Bug#21374] FrozenError message is inconsistent when a singleton method is defined on a frozen object
by andrykonchin (Andrew Konchin) 23 Nov '25

23 Nov '25

Issue #21374 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21374: FrozenError message is inconsistent when a singleton method is defined on a frozen object https://bugs.ruby-lang.org/issues/21374 * Author: andrykonchin (Andrew Konchin) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I would expect a message to contain an object class (e.g. `can't modify frozen <class>: <object#inspect>`) when an ordinary frozen object (non a module or class) is being modified. It works this way in the following example: ```ruby object = []; object.freeze; object.instance_variable_set(:@a, 42) # (irb):5:in `instance_variable_set': can't modify frozen Array: [] (FrozenError) ``` But it doesn't in the following example: ```ruby object = []; object.freeze; def object.x; end # (irb):4:in `<main>': can't modify frozen object: [] (FrozenError) ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123737] [Ruby Feature#21675] Advent of Pattern Matching
by baweaver (Brandon Weaver) 20 Nov '25

20 Nov '25

Issue #21675 has been reported by baweaver (Brandon Weaver). ---------------------------------------- Feature #21675: Advent of Pattern Matching https://bugs.ruby-lang.org/issues/21675 * Author: baweaver (Brandon Weaver) * Status: Open ---------------------------------------- Ruby pattern matching is a very useful feature, but many of the core classes to not leverage it currently. Given this I would like to directly invest in opening PRs to add this functionality and see how many cases we can reasonably add as we approach Ruby 4.0. I have already started here: * `Gem::Version` - https://github.com/ruby/ruby/pull/15109 * `Net::HTTPResponse` - https://github.com/ruby/ruby/pull/15110 * `Net::HTTPGenericRequest` - https://github.com/ruby/ruby/pull/15111 But what I am currently considering looking at first are: * `Pathname` - Path manipulation is ubiquitous. Pattern matching on path components (dirname, basename, extname) would simplify file handling logic. * `URI::Generic` - URL routing and parsing would benefit from matching on scheme, host, port, and path components. * `IPAddr` - Network programming would benefit from matching on IP address components and families for filtering and routing logic. * `File::Stat` - File metadata inspection is common. Matching on size, mode, timestamps, and file type predicates would simplify permission and type checks. * `Process::Status` - Process exit status checking is verbose. Matching on exitstatus, signals, and success state would clarify intent. * `Addrinfo` - Socket programming would benefit from matching on address family, socket type, and IP address/port for connection handling. * `OpenSSL::X509::Certificate` - Certificate validation logic could be cleaner with matching on subject, issuer, and validity dates. * `OpenSSL::X509::Name` - Distinguished name parsing for certificate handling would benefit from component extraction. * `Gem::Requirement` - Complements Gem::Version for dependency management patterns. * `Gem::Specification` - Gem metadata inspection in tooling could benefit from structured matching. If this is of interest I will start looking for more areas as well. My goal is to make this a feature that is well supported throughout common libraries in Ruby. We can use this issue as a potential staging ground for discussion of what else might make sense. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:119239] [Ruby master Feature#20750] Expose ruby_thread_has_gvl_p in ruby/thread.h
by kbrock (Keenan Brock) 19 Nov '25

19 Nov '25

Issue #20750 has been reported by kbrock (Keenan Brock). ---------------------------------------- Feature #20750: Expose ruby_thread_has_gvl_p in ruby/thread.h https://bugs.ruby-lang.org/issues/20750 * Author: kbrock (Keenan Brock) * Status: Open ---------------------------------------- Hello All, I'm hoping we can make `ruby_thread_has_gvl_p` a public method and no longer experimental. I saw the following code in a gem that was not compiling with ruby 3.3: ``` c // int ruby_thread_has_gvl_p(void); // <== line of concern if (ruby_thread_has_gvl_p()) { method_call(&context); } else { rb_thread_call_with_gvl(method_call, &context); } ``` 400 unique projects on github added the line listed above to fix compilation. [1] Some of the projects detected the method first in `extconf.rb`, but a majority just referenced it. `ffi` used to have the detection code but dropped it since the method was in all supported ruby versions. It feels like this method is now part of the undocumented public interface. My suggestion is to add the method to the real public interface in `ruby/thread.h`. PR with possible solution: https://github.com/ruby/ruby/pull/11619 Also included a patch if that is easier Thank you for your consideration, Keenan Timeline: - Dec 30 2008 - `rb_thread_call_with_gvl` introduced via 9c04a06 [2] - Jan 12 2009 - `ruby_thread_has_gvl_p` introduced via 6f09fc2 [4] - Jul 18 2012 - `rb_thread_call_with_gvl` made public via e9a91d2 [3] Current references to code: `rb_thread_call_with_gvl` [5] `ruby_thread_has_gvl_p` [6]: [1]: https://github.com/search?q=ruby_thread_has_gvl_p+language%3AC++NOT+is%3Afo… [2]: https://github.com/ruby/ruby/commit/9c04a0647fb99f7554cb2e04385ddbb970631e02 [3]: https://github.com/ruby/ruby/commit/e9a91d2c95dfe22ad0487952f7a1053ef9a5fd16 [4]: https://github.com/ruby/ruby/commit/6f09fc2efd1915c4337ce6dded52a8a8771c3222 [5]: https://github.com/ruby/ruby/blob/master/thread.c#L1878 [6]: https://github.com/ruby/ruby/blob/master/thread.c#L1923 ---Files-------------------------------- 11618.patch (3.18 KB) -- https://bugs.ruby-lang.org/

3 8

[ruby-core:123856] [Ruby Bug#21698] Should simple ArgumentError refer to Object?
by vo.x (Vit Ondruch) 19 Nov '25

19 Nov '25

Issue #21698 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #21698: Should simple ArgumentError refer to Object? https://bugs.ruby-lang.org/issues/21698 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 4.0.0dev (2025-11-18 master 85abc59c32) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Having this simple test file: ~~~ $ cat test.rb def foo(x, y) end foo(1) ~~~ This is the Ruby 3.4 behavior: ~~~ $ ruby --disable-gems test.rb test.rb:1:in 'foo': wrong number of arguments (given 1, expected 2) (ArgumentError) from test.rb:4:in '<main>' $ ruby -v ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux] ~~~ While Ruby 4.0 refers to `Object` in the backtrace: ~~~ $ ruby --disable-gems test.rb test.rb:1:in 'Object#foo': wrong number of arguments (given 1, expected 2) (ArgumentError) from test.rb:4:in '<main>' $ ruby -v ruby 4.0.0dev (2025-11-18 master 85abc59c32) +PRISM [x86_64-linux] ~~~ While this is certainly correct, I also think it is a bit confusing, because the code does not explicitly refer to `Object`. This likely comes as a result of #21543, but I think that there the original proposal for such simple case was different. I am also not convinced that the `did_you_mean` output really helps: ~~~ $ ruby test.rb test.rb:1:in 'Object#foo': wrong number of arguments (given 1, expected 2) (ArgumentError) caller: test.rb:4 | foo(1) ^^^ callee: test.rb:1 | def foo(x, y) ^^^ from test.rb:4:in '<main>' ~~~ But maybe I should just get used to it 🤷 Just FTR, I have come here trying to fix the following Sass gem test suite error on Fedora: ~~~ 1) Failure: SassScriptTest#test_shallow_argument_error_unwrapped [test/sass/script_test.rb:704]: --- expected +++ actual @@ -1 +1,3 @@ -"wrong number of arguments (1 for 0) for `arg-error'" +# encoding: ASCII-8BIT +# valid: true +"wrong number of arguments (given 1, expected 0) for `arg-error'" ~~~ The problem there is that Sass is trying to parse the backtrace: https://github.com/sass/ruby-sass/blob/7a50eae567260a23d3bbf4d5aaf1a76db43d… and changes like these breaks the compatibility. We already had to apply some [changes for Ruby 3.4](https://src.fedoraproject.org/rpms/rubygem-sass/blob/rawhide/f/rubygem… and this is yet another breakage. This is the actual difference: ~~~ --- ruby-3.4 +++ ruby-4.0 @@ -1,3 +1,3 @@ > e.backtrace => -["/builddir/build/BUILD/rubygem-sass-3.7.4-build/sass-3.7.4/usr/share/gems/gems/sass-3.7.4/test/sass/script_test.rb:11:in 'arg_error'", +["/builddir/build/BUILD/rubygem-sass-3.7.4-build/sass-3.7.4/usr/share/gems/gems/sass-3.7.4/test/sass/script_test.rb:11:in 'Sass::Script::Functions::UserFunctions#arg_error'", ~~~ Contrary to my original point, in this case the backtrace might be better. Maybe this needs more polishing? -- https://bugs.ruby-lang.org/

3 4

[ruby-core:121837] [Ruby Feature#21311] Namespace on read (revised)
by tagomoris (Satoshi Tagomori) 19 Nov '25

19 Nov '25

Issue #21311 has been reported by tagomoris (Satoshi Tagomori). ---------------------------------------- Feature #21311: Namespace on read (revised) https://bugs.ruby-lang.org/issues/21311 * Author: tagomoris (Satoshi Tagomori) * Status: Open ---------------------------------------- This replaces #19744 ## Concept This proposes a new feature to define virtual top-level namespaces in Ruby. Those namespaces can require/load libraries (either .rb or native extension) separately from other namespaces. Dependencies of required/loaded libraries are also required/loaded in the namespace. This feature will be disabled by default at first, and will be enabled by an env variable `RUBY_NAMESPACE=1` as an experimental feature. (It could be enabled by default in the future possibly.) ### "on read" approach The "on write" approach here is the design to define namespaces on the loaded side. For example, Java packages are defined in the .java files and it is required to separate namespaces from each other. It can be implemented very easily, but it requires all libraries to be updated with the package declaration. (In my opinion, it's almost impossible in the Ruby ecosystem.) The "on read" approach is to create namespaces and then require/load applications and libraries in them. Programmers can control namespace separation at the "read" time. So, we can introduce the namespace separation incrementally. ## Motivation The "namespace on read" can solve the 2 problems below, and can make a path to solve another problem: * Avoiding name conflicts between libraries * Applications can require two different libraries safely which use the same module name. * Avoiding unexpected globally shared modules/objects * Applications can make an independent/unshared module instance. * Multiple versions of gems can be required * Application developers will have fewer version conflicts between gem dependencies if rubygems/bundler will support the namespace on read. (Support from RubyGems/Bundler and/or other packaging systems will be needed) For the motivation details, see [Feature #19744]. ## How we can use Namespace ```ruby # app1.rb PORT = 2048 class App def self.port = ::PORT def val = PORT.to_s end p App.port # 2048 # app2.rb class Number def double = self * 2 end PORT = 2048.double class App def self.port = ::PORT def val = PORT.double.to_s end p App.port # 4096 # main.rb - executed as `ruby main.rb` ns1 = Namespace.new ns1.require('./app1') # 2048 ns2 = Namespace.new ns2.require('./app2') # 4096 PORT = 8080 class App def self.port = ::PORT def val = PORT.to_s end p App.port # 8080 p App.val # "8080" p ns1::App.port # 2048 p ns1::App.val # "2048" p ns2::App.port # 4096 p ns2::App.val # "8192" 1.double # NoMethodError ``` ## Namespace specification ### Types of namespaces There are two namespace types, "root" and "user" namespace. "Root" namespace exists solely in a Ruby process, and "user" namespaces can be created as many as Ruby programmers want. ### Root namespace Root namespace is a unique namespace to be defined when a Ruby process starts. It only contains built-in classes/modules/constants, which are available without any `require` calls, including RubyGems itself (when `--disable-gems` is not specified). ### User namespace User namespace is a namespace to run users' Ruby scripts. The "main" namespace is the namespace to run the user's `.rb` script specified by the `ruby` command-line argument. Other user namespaces ("optional" namespaces) can be created by `Namespace.new` call. In user namespace (both main and optional namespaces), built-in class/module definitions are copied from the root namespace, and other new classes/modules are defined in the namespace, separately from other (root/user) namespaces. The newly defined classes/modules are top-level classes/modules in the main namespace like `App`, but in optional namespaces, classes/modules are defined under the namespace (subclass of Module), like `ns::App`. In that namespace `ns`, `ns::App` is accessible as `App` (or `::App`). There is no way to access `App` in the main namespace from the code in the different namespace `ns`. ### Constants, class variables and global variables Constants, Class variables of built-in classes and global variables are also separated by namespace. Values set to class/global variables in a namespace are invisible in other namespaces. ### Methods and procs Methods defined in a namespace run with the defined namespace, even when called from other namespaces. Procs created in a namespace run with the defined namespace too. ### Dynamic link libraries Dynamic link libraries (typically .so files) are also loaded in namespaces as well as .rb files. ### Open class (Changes on built-in classes) In user namespaces, built-in class definitions can be modified. But those operations are processed as copy-on-write of class definition from the root namespace, and the changed definitions are visible only in the (user) namespace. Definitions in the root namespace are not modifiable from other namespaces. Methods defined in the root namespace run only with root-namespace definitions. ## Enabling Namespace Specify `RUBY_NAMESPACE=1` environment variable when starting Ruby processes. `1` is the only valid value here. Namespace feature can be enabled only when Ruby processes start. Setting `RUBY_NAMESPACE=1` after starting Ruby scripts performs nothing. ## Pull-request https://github.com/ruby/ruby/pull/13226 -- https://bugs.ruby-lang.org/

19 110

[ruby-core:123854] [Ruby Bug#21697] `nmake up` will update broken `revision.h`
by hsbt (Hiroshi SHIBATA) 19 Nov '25

19 Nov '25

Issue #21697 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21697: `nmake up` will update broken `revision.h` https://bugs.ruby-lang.org/issues/21697 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In 4.0.0-preview2 package, `nmake up` generate the broken `revision.h`. I could reproduce this: ``` PS C:\Users\hsbt\Downloads> Invoke-WebRequest https://cache.ruby-lang.org/pub/ruby/4.0/ruby-4.0.0-preview2.zip -OutFile ruby-4.0.0-preview2.zip (snip) PS C:\Users\hsbt\Downloads> unzip .\ruby-4.0.0-preview2.zip Archive: ./ruby-4.0.0-preview2.zip creating: ruby-4.0.0-preview2/ (snip) inflating: ruby-4.0.0-preview2/zjit.rbinc PS C:\Users\hsbt\Downloads> cd .\ruby-4.0.0-preview2 PS C:\Users\hsbt\Downloads\ruby-4.0.0-preview2> cmd /k "C:\Program Files (x86)\Microsoft Visual Studio\18\BuildTools\VC\Auxiliary\Build\vcvars64.bat" hsbt@LAPLACE C:\Users\hsbt\Downloads\ruby-4.0.0-preview2>type revision.h #define RUBY_REVISION "4fa6e9938c" #define RUBY_FULL_REVISION "4fa6e9938cfb9458abd876ad4219a6648bfe1c96" #define RUBY_RELEASE_YEAR 2025 #define RUBY_RELEASE_MONTH 11 #define RUBY_RELEASE_DAY 17 hsbt@LAPLACE C:\Users\hsbt\Downloads\ruby-4.0.0-preview2>nmake up hsbt@LAPLACE C:\Users\hsbt\Downloads\ruby-4.0.0-preview2>win32\configure.bat Creating verconf.mk type 'nmake' to make ruby. hsbt@LAPLACE C:\Users\hsbt\Downloads\ruby-4.0.0-preview2>nmake up Microsoft(R) Program Maintenance Utility Version 14.50.35717.0 Copyright (C) Microsoft Corporation. All rights reserved. Downloading bundled gem files... revision.h updated Downloading bundled gem files... (snip) Extracting bundled gem files... hsbt@LAPLACE C:\Users\hsbt\Downloads\ruby-4.0.0-preview2>type revision.h #define RUBY_RELEASE_YEAR 2025 #define RUBY_RELEASE_MONTH 11 #define RUBY_RELEASE_DAY 19 ``` `RUBY_REVISION` and `RUBY_FULL_REVISION` is lost now. This caused the issue at release time of 4.0.0-preview2. We added the workaround at https://github.com/ruby/actions/commit/1561918fc1c929ee9ac4c2dd91af7870024a… -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122303] [Ruby Bug#21375] Set[] does not call #initialize
by Ethan (Ethan -) 18 Nov '25

18 Nov '25

Issue #21375 has been reported by Ethan (Ethan -). ---------------------------------------- Bug #21375: Set[] does not call #initialize https://bugs.ruby-lang.org/issues/21375 * Author: Ethan (Ethan -) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-26T17:42:35Z master 909a0daab6) +PRISM [x86_64-darwin22] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I have a subclass of Set that overrides #initialize. Following #21216, .new does call #initialize but .[] does not. ```ruby class MySet < Set def initialize(enum = nil) compare_by_identity super end end MySet.new.compare_by_identity? # => true MySet[].compare_by_identity? # => false ``` -- https://bugs.ruby-lang.org/

6 10