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

[ruby-core:121683] [Ruby Bug#21272] Class.new doesn't trigger :class TracePoint
by st0012 (Stan Lo) 26 Apr '25

26 Apr '25

Issue #21272 has been reported by st0012 (Stan Lo). ---------------------------------------- Bug #21272: Class.new doesn't trigger :class TracePoint https://bugs.ruby-lang.org/issues/21272 * Author: st0012 (Stan Lo) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- According to the official [documentation](https://docs.ruby-lang.org/en/master/TracePoint.html#class-T…: > To filter what is traced, you can pass any of the following as events: > > :class > Start a class or module definition. I'd expect `:class` events to be triggered when new classes are defined via `Class.new` as well, but currently that's not the case. Should we either support `Class.new`, or clarify the behaviour in documentation? ### Reproduction ```rb TracePoint.trace(:class) do |tp| puts "Class created at line: #{tp.lineno}" end class Foo; end # Triggers the tracepoint Baz = Class.new # Doesn't trigger the tracepoint # ruby test.rb # Class created at line: 5 ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:121731] [Ruby Bug#21285] Range#overlap? returns false for (nil..nil)
by andrykonchin (Andrew Konchin) 26 Apr '25

26 Apr '25

Issue #21285 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21285: Range#overlap? returns false for (nil..nil) https://bugs.ruby-lang.org/issues/21285 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.4.3 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I've notices the following edge case: ```ruby (..1).overlap?(nil..nil) => false ``` But I expect `true` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121560] [Ruby Feature#21221] Proposal to upstream ZJIT
by maximecb (Maxime Chevalier-Boisvert) 25 Apr '25

25 Apr '25

Issue #21221 has been reported by maximecb (Maxime Chevalier-Boisvert). ---------------------------------------- Feature #21221: Proposal to upstream ZJIT https://bugs.ruby-lang.org/issues/21221 * Author: maximecb (Maxime Chevalier-Boisvert) * Status: Open * Assignee: maximecb (Maxime Chevalier-Boisvert) * Target version: 3.5 ---------------------------------------- # Background For the past 3 months, the YJIT team at Shopify has been working on a next-generation Ruby JIT, which we refer to as ZJIT. This new compiler is currently being developed in a private fork, with the hope that we can eventually upstream it into ruby/ruby. Maxime Chevalier-Boisvert will give a talk at RubyKaigi 2025 to officially announce the project to the Ruby community and the broader public. # Design of ZJIT YJIT compiles YARV bytecode more or less directly to machine code. This has the benefit that YJIT compiles code fast and that it’s a relatively simple architecture, which was helpful in building the compiler incrementally. The downside is that YJIT is difficult to extend and build upon. In particular, YJIT is very limited when it comes to optimizations that cross YARV instruction boundaries. We’ve known for some time that in order to unlock higher levels of performance, a Ruby JIT would need the ability to perform more aggressive inlining, but it is challenging to cleanly do this in YJIT. The main innovation of ZJIT is that it has its own Static Single Assignment (SSA) Intermediate Representation (IR). YARV bytecode is converted into this IR, which can then be optimized using multiple optimization passes. These passes can be orthogonal and modular to some degree, which makes the design of the compiler easier to reason about, easier to extend and also opens up the possibility of having multiple JIT compilation tiers in the future, which is something that both Matz and Takashi Kokubun have hoped to see in a Ruby JIT for some time. In addition to this, we are moving to a more traditional method-based JIT compiler design. I (Maxime) have had the chance to help build and deploy Lazy Basic Block Versioning (LBBV), an offshoot of my PhD research into a production compiler, an opportunity which I’m very thankful for. However, I feel like ZJIT might benefit from having a compiler architecture that is more “standard”. With YJIT, we’ve had very few contributions from Ruby Core contributors outside of Shopify. I’m hoping that if we build a compiler with an architecture that is more textbook-like, we could have a project that is more approachable for new contributors and thus more inclusive of other Ruby core members outside of Shopify, which would be great for the long-term future of Ruby. # Current Status It is still early days for ZJIT. We are only 3 months into its development. As such, ZJIT is currently very much incomplete and can only run small tests and microbenchmarks. Nonetheless, we would still like to upstream it because developing in a fork makes it much harder to keep up with upstream changes in Ruby. We’re hoping to bring it much farther along this year, and we believe that ZJIT will be fairly unintrusive in the upstream repo given that it will have no more dependencies than YJIT, and it will also be guarded by a command-line switch. Ruby 3.5 / 2025 Objectives Our goal for the end of the year is to bring ZJIT approximately at parity with YJIT in terms of performance. We expect that it will be relatively easy to outperform YJIT on small microbenchmarks, but that matching YJIT’s performance across larger Ruby programs will take several months because of the breadth of Ruby features used. It is non-trivial to efficiently handle megamorphic call sites making use of keyword arguments, for instance. It should not be difficult to bring ZJIT at parity with YJIT in terms of supported/unsupported Ruby features, because the JIT compiler can always fall back to the interpreter for any feature it doesn’t support. Some features we aim to implement/complete in time for Ruby 3.5: - Fast JIT-to-JIT calls using a custom calling convention - Polymorphic inline caches - Support for full deoptimization (e.g. for TracePoint) - Ability to deoptimize single functions (e.g. method redefined, caller gets deoptimized) - Side-exit much less often than YJIT (crucial for good performance) - Ability to serialize machine code - Dead-code elimination, constant propagation - Fusion of comparison and branch instructions Stretch goals and longer-term goals: - Support two JIT compilation tiers - Aggressive inlining of Ruby calls - Optimize GC allocations - Allocation elision to speed up allocations and reduce GC pressure We are currently using a modified/improved version of the YJIT backend to generate machine code. This means ZJIT is coming out of the gate with support for both x86-64 and arm64, as YJIT did. The ability to serialize machine code is something that we hope to be able to implement in ZJIT. This would allow us to save compiled code and reuse it in future executions of a given program. This would enable faster startup times. We know from experience that this is important in production environments such as Shopify’s where code can be (re)deployed several times a day, but it also makes sense on a smaller scale where individuals run code on a personal computer and can benefit from software starting up faster. # Merging Logistics Like its predecessor, ZJIT is written in Rust, and has very few dependencies by design. In particular, there are no external dependencies outside of the Rust compiler (rustc) to build ZJIT with Ruby. Given that it is very early in ZJIT’s development process, we would like to upstream ZJIT without replacing YJIT, so as to ensure that Ruby 3.5 ships with a well-tested, production-ready JIT. As with YJIT, we would like to suggest that ZJIT should be guarded by a --zjit command-line switch. Since using the compiler is opt-in, there is very little risk for the average Ruby user. We can adjust the way we advertise ZJIT at the time of the Ruby 3.5 release and how much we want the broader Ruby community to try it based on its level of maturity at that point. If ZJIT is not sufficiently mature, we can simply tell people that it is experimental and only for enthusiasts, and recommend that they use YJIT instead. We are currently developing ZJIT using Rust 1.85.0 so that we can use the 2024 edition of Rust. This shouldn’t be a problem since Rust can easily be installed using the rustup tool, and if a sufficiently recent Rust compiler is not available, CRuby can still build without ZJIT, or with YJIT only (YJIT requires rustc 1.58.0). In terms of build strategy, if a recent version of the Rust cargo tool is installed, it may be possible to automatically build both YJIT and ZJIT in the same binary. Otherwise, YJIT could be built without ZJIT as long as rustc 1.58.0 or more a recent version is available. If neither is available, then CRuby can be built without either JIT as a fallback. Another possibility, if we want to be more conservative for Ruby 3.5, is to only enable building ZJIT if configure is run with an explicit --enable-zjit. We can potentially make this decision closer to the end of the year. The timeline for upstreaming would be in the 4 to 6 weeks following RubyKaigi. To merge ZJIT upstream, we will rebase the commits on ruby/ruby‘s master branch and generally preserve the commit history. Some commit messages will be cleaned up and improved prior to merging. Some commits which are logically related may be squashed together. We will only enable a small subset of CI tests for ZJIT at first, so as to keep all tests passing. -- https://bugs.ruby-lang.org/

4 7

[ruby-core:121719] [Ruby Bug#21282] `FrozenError` raised by `rb_error_frozen_object` should mention real class of frozen object
by sanjioh (Fabio Sangiovanni) 25 Apr '25

25 Apr '25

Issue #21282 has been reported by sanjioh (Fabio Sangiovanni). ---------------------------------------- Bug #21282: `FrozenError` raised by `rb_error_frozen_object` should mention real class of frozen object https://bugs.ruby-lang.org/issues/21282 * Author: sanjioh (Fabio Sangiovanni) * Status: Open * ruby -v: ruby 3.5.0dev (2025-04-23T14:19:58Z fix-frozenerror-me.. 5c9dd42e27) +PRISM [x86_64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hello everyone, I've noticed that the following snippets both raise `FrozenError`, but with different messages: ``` ruby Object.new.freeze.instance_variable_set(:@test, true) # can't modify frozen Object: #<Object:0x000000010b4d8aa8> (FrozenError) ``` ``` ruby Object.new.freeze.tap(&:singleton_class).instance_variable_set(:@test, true) # can't modify frozen #<Class:#<Object:0x0000000101538a98>>: #<Object:0x0000000101538a98> (FrozenError) ``` As you can see, the second example mentions the singleton class of the object, while I would expect `Object` to be mentioned in its place, as the first example does. From what I can see in `test/ruby/test_frozen_error.rb`, the expected behavior here should be to display the real class of the frozen object (as returned by `Kernel#class`), independently of the existence of a singleton class. I'm working on a PR that should fix this (will post the link in the comments in a moment). Cheers! -- https://bugs.ruby-lang.org/

1 2

[ruby-core:121712] [Ruby Feature#15408] Deprecate object_id and _id2ref
by byroot (Jean Boussier) 23 Apr '25

23 Apr '25

Issue #15408 has been updated by byroot (Jean Boussier). I opened a PR to finally deprecated `ObjectSpace._id2ref`: https://github.com/ruby/ruby/pull/13157 ---------------------------------------- Feature #15408: Deprecate object_id and _id2ref https://bugs.ruby-lang.org/issues/15408#change-112765 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: headius (Charles Nutter) ---------------------------------------- Ruby currently provides the object_id method to get a "identifier" for a given object. According to the documentation, this ID is the same for every object_id call against a given object, and guaranteed not to be the same as any other active (i.e. alive) object. However, no guarantee is made about the ID being reused for a future object after the original has been garbage collected. As a result, object_id can't be used to uniquely identify any object that might be garbage collected, since that ID may be associated with a completely different object in the future. Ruby also provides a method to go from an object_id to the object reference itself: ObjectSpace._id2ref. This method has been in Ruby for decades and is often used to implement a weak hashmap from ID to reference, since holding the ID will not keep the object alive. However due to the problems with object_id not actually being unique, it's possible for _id2ref to return a different object than originally had that ID as object slots are reused in the heap. The only way to implement object_id safely (with idempotency guarantees) would be to assign to all objects a monotonically-increasing ID. Alternatively, this ID could be assigned lazily only for those objects on which the code calls object_id. JRuby implements object_id in this way currently. The only way to implement _id2ref safely would be to have a mapping in memory from those monotonically-increasing IDs to the actual objects. This would have to be a weak mapping to prevent the objects from being garbage collected. JRuby currently only supports _id2ref via a flag, since the additional overhead of weakly tracking every requested object_id is extremely high. An alternative for MRI would be to implement _id2ref as a heap scan, as it is implemented in Rubinius. This would make it entirely unpractical due to the cost of scanning the heap for every ID lookup. I propose that both methods should immediately be deprecated for removal in Ruby 3.0. * They do not do what people expect. * They cannot reliably do what they claim to do. * They eventually lead to difficult-to-diagnose bugs in every possible use case. Put simply, both methods have always been broken in MRI and making them unbroken would render them useless. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121696] [Ruby Bug#21276] Regression segfault instead of exception `require': cannot load such file
by wsfulton (William Fulton) 22 Apr '25

22 Apr '25

Issue #21276 has been reported by wsfulton (William Fulton). ---------------------------------------- Bug #21276: Regression segfault instead of exception `require': cannot load such file https://bugs.ruby-lang.org/issues/21276 * Author: wsfulton (William Fulton) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- A segfault occurs instead of a Ruby exception in one or the test cases we have in SWIG. I've run a git bisect on the 3.2 releases to identify commit 2aaa9af75989bb0993a44e9690ed2ca890b2ff91 for when the segfault begins: commit 2aaa9af75989bb0993a44e9690ed2ca890b2ff91 Author: nagachika <nagachika(a)ruby-lang.org> Date: Thu Nov 9 17:36:42 2023 +0900 merge revision(s) 4329554f171fdb483cafa672df5f2a08741940c5,b5c74d548872388921402ff2db36be15e924a89b: [Backport #19985] [Bug #19985] Raise LoadError with the converted feature name `Kernel#require` converts feature name objects that have the `to_path` method such as `Pathname`, but had used the original object on error and had resulted in an unexpected `TypeError`. --- load.c | 14 +++++++++++--- test/ruby/test_require.rb | 26 +++++++++++++++++++++----- 2 files changed, 32 insertions(+), 8 deletions(-) Ease the `Encoding::CompatibilityError` test failure At the time this test first started using `assert_raise_with_message`, it did not touch `Encoding.default_internal`. --- test/ruby/test_require.rb | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) So, ruby-3.2.2 is okay and 3.2.3 has the regression. Still present with ruby-3.2.8. I'll provide two ways to replicate. 1. Using SWIG built from source: 1a. clone SWIG from github and build SWIG using steps 1. and 2. from https://swig.org/svn.html. Note that you can specify a custom build of ruby to use with: ./configure --with-ruby=/my-path-to-ruby-installation/bin/ruby 1b. cd Examples/test-suite/ruby 1c. make import_fragments.cpptest CXXFLAGS=-g This is my output using ruby version 3.2.3 (ruby git tag v3_2_3): ~/swig/github/wsfulton/swig/Examples/test-suite/ruby (master >)$ make import_fragments.cpptest CXXFLAGS=-g if [ -f ./import_fragments_runme.rb ]; then echo "checking ruby testcase import_fragments (with run test)" ; else echo "checking ruby testcase import_fragments" ; fi checking ruby testcase import_fragments (with run test) make -f ../../../Examples/Makefile SRCDIR='./' CXXSRCS='' SWIG_LIB_DIR='../../../Lib' SWIGEXE='../../../swig' INCLUDES='-I../../../Examples/test-suite' SWIGOPT='-outcurrentdir -I../../../Examples/test-suite -w801 -noautorename -features autodoc=4 -Werror' NOLINK=true TARGET='import_fragments' INTERFACEDIR='../' INTERFACE='import_fragments.i' ruby_cpp make[1]: Entering directory '/home/william/swig/github/wsfulton/swig/Examples/test-suite/ruby' env SWIG_LIB=../../../Lib ../../../swig -c++ -ruby -outcurrentdir -I../../../Examples/test-suite -w801 -noautorename -features autodoc=4 -Werror -o import_fragments_wrap.cxx ./../import_fragments.i g++ -c -fPIC -I. -I./ -g -fPIC import_fragments_wrap.cxx -I../../../Examples/test-suite -I/home/william/install/ruby-3_2_3-debug/include/ruby-3.2.0 -I/home/william/install/ruby-3_2_3-debug/include/ruby-3.2.0/x86_64-linux g++ -shared -g import_fragments_wrap.o -o import_fragments.so make[1]: Leaving directory '/home/william/swig/github/wsfulton/swig/Examples/test-suite/ruby' if [ -f ./import_fragments_runme.rb ]; then env LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH /home/william/install/ruby-3_2_3-debug/bin/ruby -I.:. ./import_fragments_runme.rb; elif [ -f ./import_fragments.so ] ; then env LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH /home/william/install/ruby-3_2_3-debug/bin/ruby -I.:. -r./import_fragments.so -e '' ; fi <internal:/home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:151: [BUG] Segmentation fault at 0x000000000000000a ruby 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0004 p:0018 s:0029 e:000026 RESCUE <internal:/home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:151 c:0003 p:0275 s:0023 e:000022 METHOD <internal:/home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:40 c:0002 p:0014 s:0008 E:002010 EVAL ./import_fragments_runme.rb:15 [FINISH] c:0001 p:0000 s:0003 E:000bf0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- ./import_fragments_runme.rb:15:in `<main>' <internal:/home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:40:in `require' <internal:/home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:151:in `rescue in require' -- Machine register context ------------------------------------------------ RIP: 0x000057fa8949081d RBP: 0x00007ffdd0182518 RSP: 0x00007ffdd0182518 RAX: 0x000000000000000a RBX: 0x000057fa94261250 RCX: 0x000000000000008c RDX: 0x000000000000008c RDI: 0x000000000000000a RSI: 0x000000000000008c R8: 0x0000000000000845 R9: 0x0000000000000020 R10: 0x000057fa94071fc0 R11: 0x0000000000000040 R12: 0x0000000000000003 R13: 0x0000000000000000 R14: 0x000057fa94261260 R15: 0x00007b246ad86f10 EFL: 0x0000000000010283 -- C level backtrace information ------------------------------------------- /home/william/install/ruby-3_2_3-debug/bin/ruby(rb_print_backtrace+0x20) [0x57fa8950f75c] ../vm_dump.c:785 /home/william/install/ruby-3_2_3-debug/bin/ruby(rb_vm_bugreport+0x198) [0x57fa8950fd07] ../vm_dump.c:1080 /home/william/install/ruby-3_2_3-debug/bin/ruby(rb_bug_for_fatal_signal+0x12c) [0x57fa895b3000] /home/william/install/ruby-3_2_3-debug/bin/ruby(sigsegv+0x74) [0x57fa8945b1be] ../signal.c:964 /home/william/install/ruby-3_2_3-debug/bin/ruby(sigill) (null):0 /lib/x86_64-linux-gnu/libc.so.6(0x7b246aa45330) [0x7b246aa45330] /home/william/install/ruby-3_2_3-debug/bin/ruby(hash_table_index+0x13) [0x57fa8949081d] ../id_table.c:132 /home/william/install/ruby-3_2_3-debug/bin/ruby(rb_id_table_lookup+0x38) [0x57fa89490bb5] ../id_table.c:230 /home/william/install/ruby-3_2_3-debug/bin/ruby(vm_search_cc+0x6e) [0x57fa894db233] ../vm_insnhelper.c:1988 /home/william/install/ruby-3_2_3-debug/bin/ruby(rb_vm_search_method_slowpath+0x51) [0x57fa894db4b3] ../vm_insnhelper.c:2084 /home/william/install/ruby-3_2_3-debug/bin/ruby(vm_search_method_slowpath0+0x2e) [0x57fa894db51a] ../vm_insnhelper.c:2106 /home/william/install/ruby-3_2_3-debug/bin/ruby(vm_search_method_fastpath+0x66) [0x57fa894db614] ../vm_insnhelper.c:2172 /home/william/install/ruby-3_2_3-debug/bin/ruby(vm_search_method) ../vm_insnhelper.c:2182 /home/william/install/ruby-3_2_3-debug/bin/ruby(vm_method_cfunc_is+0x2f) [0x57fa894db693] ../vm_insnhelper.c:2237 /home/william/install/ruby-3_2_3-debug/bin/ruby(opt_equality+0x6a) [0x57fa894db990] ../vm_insnhelper.c:2324 /home/william/install/ruby-3_2_3-debug/bin/ruby(vm_exec_core+0x5983) [0x57fa894efa06] ../insns.def:1174 /home/william/install/ruby-3_2_3-debug/bin/ruby(rb_vm_exec+0x1a8) [0x57fa8950499c] ../vm.c:2383 /home/william/install/ruby-3_2_3-debug/bin/ruby(rb_iseq_eval_main+0x42) [0x57fa89505731] ../vm.c:2633 /home/william/install/ruby-3_2_3-debug/bin/ruby(rb_ec_exec_node+0x125) [0x57fa892deeb9] ../eval.c:289 /home/william/install/ruby-3_2_3-debug/bin/ruby(ruby_run_node+0x96) [0x57fa892df026] ../eval.c:330 /home/william/install/ruby-3_2_3-debug/bin/ruby(rb_main+0x4c) [0x57fa892da455] ../main.c:38 /home/william/install/ruby-3_2_3-debug/bin/ruby(main+0x62) [0x57fa892da4cd] ../main.c:57 -- Other runtime information ----------------------------------------------- * Loaded script: ./import_fragments_runme.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb 6 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/enc/encdb.so 7 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/enc/trans/transdb.so 8 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/rbconfig.rb 9 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/compatibility.rb 10 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/defaults.rb 11 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/deprecate.rb 12 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/errors.rb 13 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/unknown_command_spell_checker.rb 14 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/exceptions.rb 15 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/basic_specification.rb 16 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/stub_specification.rb 17 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/platform.rb 18 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/util/list.rb 19 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/version.rb 20 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/requirement.rb 21 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/specification.rb 22 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/util.rb 23 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems/core_ext/kernel_gem.rb 24 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/monitor.so 25 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/monitor.rb 26 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/rubygems.rb 27 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/error_highlight/version.rb 28 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/error_highlight/base.rb 29 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/error_highlight/formatter.rb 30 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/error_highlight/core_ext.rb 31 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/error_highlight.rb 32 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/did_you_mean/version.rb 33 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/did_you_mean/core_ext/name_error.rb 34 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/did_you_mean/levenshtein.rb 35 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/did_you_mean/jaro_winkler.rb 36 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/did_you_mean/spell_checker.rb 37 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/did_you_mean/spell_checkers/name_error_checkers/class_name_checker.rb 38 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/did_you_mean/spell_checkers/name_error_checkers/variable_name_checker.rb 39 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/did_you_mean/spell_checkers/name_error_checkers.rb 40 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/did_you_mean/spell_checkers/method_name_checker.rb 41 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/did_you_mean/spell_checkers/key_error_checker.rb 42 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/did_you_mean/spell_checkers/null_checker.rb 43 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/did_you_mean/tree_spell_checker.rb 44 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/did_you_mean/spell_checkers/require_path_checker.rb 45 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/did_you_mean/spell_checkers/pattern_key_name_checker.rb 46 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/did_you_mean/formatter.rb 47 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/did_you_mean.rb 48 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/syntax_suggest/core_ext.rb 49 /home/william/swig/github/wsfulton/swig/Examples/test-suite/ruby/swig_assert.rb * Process memory map: 57fa892aa000-57fa892d9000 r--p 00000000 103:06 30818930 /home/william/install/ruby-3_2_3-debug/bin/ruby 57fa892d9000-57fa895c5000 r-xp 0002f000 103:06 30818930 /home/william/install/ruby-3_2_3-debug/bin/ruby 57fa895c5000-57fa8974e000 r--p 0031b000 103:06 30818930 /home/william/install/ruby-3_2_3-debug/bin/ruby 57fa8974e000-57fa89757000 r--p 004a4000 103:06 30818930 /home/william/install/ruby-3_2_3-debug/bin/ruby 57fa89757000-57fa89758000 rw-p 004ad000 103:06 30818930 /home/william/install/ruby-3_2_3-debug/bin/ruby 57fa89758000-57fa8976d000 rw-p 00000000 00:00 0 57fa94047000-57fa9435c000 rw-p 00000000 00:00 0 [heap] 7b2464200000-7b2464407000 r--s 00000000 103:04 407927 /usr/lib/x86_64-linux-gnu/libc.so.6 7b2464600000-7b24650bb000 r--s 00000000 103:06 30818930 /home/william/install/ruby-3_2_3-debug/bin/ruby 7b2465200000-7b246529d000 r--p 00000000 103:04 408519 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33 7b246529d000-7b24653e5000 r-xp 0009d000 103:04 408519 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33 7b24653e5000-7b246546c000 r--p 001e5000 103:04 408519 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33 7b246546c000-7b2465477000 r--p 0026b000 103:04 408519 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33 7b2465477000-7b246547a000 rw-p 00276000 103:04 408519 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33 7b246547a000-7b246547e000 rw-p 00000000 00:00 0 7b24655b7000-7b24655b8000 ---p 00000000 00:00 0 7b24655b8000-7b2465659000 rw-p 00000000 00:00 0 7b2465659000-7b246565a000 ---p 00000000 00:00 0 7b246565a000-7b24656fb000 rw-p 00000000 00:00 0 7b24656fb000-7b24656fc000 ---p 00000000 00:00 0 7b24656fc000-7b246579d000 rw-p 00000000 00:00 0 7b246579d000-7b246579e000 ---p 00000000 00:00 0 7b246579e000-7b246583f000 rw-p 00000000 00:00 0 7b246583f000-7b2465840000 ---p 00000000 00:00 0 7b2465840000-7b24658e1000 rw-p 00000000 00:00 0 7b24658e1000-7b24658e2000 ---p 00000000 00:00 0 7b24658e2000-7b2465983000 rw-p 00000000 00:00 0 7b2465983000-7b2465984000 ---p 00000000 00:00 0 7b2465984000-7b2465a25000 rw-p 00000000 00:00 0 7b2465a25000-7b2465a26000 ---p 00000000 00:00 0 7b2465a26000-7b2465ac7000 rw-p 00000000 00:00 0 7b2465ac7000-7b2465ac8000 ---p 00000000 00:00 0 7b2465ac8000-7b2465b69000 rw-p 00000000 00:00 0 7b2465b69000-7b2465b6a000 ---p 00000000 00:00 0 7b2465b6a000-7b2465c0b000 rw-p 00000000 00:00 0 7b2465c0b000-7b2465c0c000 ---p 00000000 00:00 0 7b2465c0c000-7b2465cad000 rw-p 00000000 00:00 0 7b2465cad000-7b2465cae000 ---p 00000000 00:00 0 7b2465cae000-7b2465d4f000 rw-p 00000000 00:00 0 7b2465d4f000-7b2465d50000 ---p 00000000 00:00 0 7b2465d50000-7b2465df1000 rw-p 00000000 00:00 0 7b2465df1000-7b2465df2000 ---p 00000000 00:00 0 7b2465df2000-7b2465e93000 rw-p 00000000 00:00 0 7b2465e93000-7b2465e94000 ---p 00000000 00:00 0 7b2465e94000-7b2465f35000 rw-p 00000000 00:00 0 7b2465f35000-7b2465f36000 ---p 00000000 00:00 0 7b2465f36000-7b2465fd7000 rw-p 00000000 00:00 0 7b2465fd7000-7b2465fd8000 ---p 00000000 00:00 0 7b2465fd8000-7b2466079000 rw-p 00000000 00:00 0 7b2466079000-7b246607a000 ---p 00000000 00:00 0 7b246607a000-7b246611b000 rw-p 00000000 00:00 0 7b246611b000-7b246611c000 ---p 00000000 00:00 0 7b246611c000-7b24661bd000 rw-p 00000000 00:00 0 7b24661bd000-7b24661be000 ---p 00000000 00:00 0 7b24661be000-7b246625f000 rw-p 00000000 00:00 0 7b246625f000-7b2466260000 ---p 00000000 00:00 0 7b2466260000-7b2466301000 rw-p 00000000 00:00 0 7b2466301000-7b2466302000 ---p 00000000 00:00 0 7b2466302000-7b24663a3000 rw-p 00000000 00:00 0 7b24663a3000-7b24663a4000 ---p 00000000 00:00 0 7b24663a4000-7b2466445000 rw-p 00000000 00:00 0 7b2466445000-7b2466446000 ---p 00000000 00:00 0 7b2466446000-7b24664e7000 rw-p 00000000 00:00 0 7b24664e7000-7b24664e8000 ---p 00000000 00:00 0 7b24664e8000-7b2466589000 rw-p 00000000 00:00 0 7b2466589000-7b246658a000 ---p 00000000 00:00 0 7b246658a000-7b246662b000 rw-p 00000000 00:00 0 7b246662b000-7b246662c000 ---p 00000000 00:00 0 7b246662c000-7b24666cd000 rw-p 00000000 00:00 0 7b24666cd000-7b24666ce000 ---p 00000000 00:00 0 7b24666ce000-7b246676f000 rw-p 00000000 00:00 0 7b246676f000-7b2466770000 ---p 00000000 00:00 0 7b2466770000-7b2466811000 rw-p 00000000 00:00 0 7b2466811000-7b2466812000 ---p 00000000 00:00 0 7b2466812000-7b24668b3000 rw-p 00000000 00:00 0 7b24668b3000-7b24668b4000 ---p 00000000 00:00 0 7b24668b4000-7b2466955000 rw-p 00000000 00:00 0 7b2466955000-7b2466956000 ---p 00000000 00:00 0 7b2466956000-7b24669f7000 rw-p 00000000 00:00 0 7b24669f7000-7b2469a00000 rw-p 00000000 00:00 0 7b2469a12000-7b2469a16000 r--p 00000000 103:04 408078 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7b2469a16000-7b2469a3a000 r-xp 00004000 103:04 408078 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7b2469a3a000-7b2469a3e000 r--p 00028000 103:04 408078 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7b2469a3e000-7b2469a3f000 r--p 0002b000 103:04 408078 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7b2469a3f000-7b2469a40000 rw-p 0002c000 103:04 408078 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7b2469a40000-7b2469a70000 rw-p 00000000 00:00 0 7b2469aa0000-7b2469b80000 rw-p 00000000 00:00 0 7b2469b8f000-7b2469c00000 rw-p 00000000 00:00 0 7b2469c00000-7b246a9ec000 r--p 00000000 103:04 398501 /usr/lib/locale/locale-archive 7b246aa00000-7b246aa28000 r--p 00000000 103:04 407927 /usr/lib/x86_64-linux-gnu/libc.so.6 7b246aa28000-7b246abb0000 r-xp 00028000 103:04 407927 /usr/lib/x86_64-linux-gnu/libc.so.6 7b246abb0000-7b246abff000 r--p 001b0000 103:04 407927 /usr/lib/x86_64-linux-gnu/libc.so.6 7b246abff000-7b246ac03000 r--p 001fe000 103:04 407927 /usr/lib/x86_64-linux-gnu/libc.so.6 7b246ac03000-7b246ac05000 rw-p 00202000 103:04 407927 /usr/lib/x86_64-linux-gnu/libc.so.6 7b246ac05000-7b246ac12000 rw-p 00000000 00:00 0 7b246ac26000-7b246ac28000 r--p 00000000 103:06 5909120 /home/william/swig/github/wsfulton/swig/Examples/test-suite/ruby/import_fragments.so 7b246ac28000-7b246ac2c000 r-xp 00002000 103:06 5909120 /home/william/swig/github/wsfulton/swig/Examples/test-suite/ruby/import_fragments.so 7b246ac2c000-7b246ac2e000 r--p 00006000 103:06 5909120 /home/william/swig/github/wsfulton/swig/Examples/test-suite/ruby/import_fragments.so 7b246ac2e000-7b246ac2f000 r--p 00007000 103:06 5909120 /home/william/swig/github/wsfulton/swig/Examples/test-suite/ruby/import_fragments.so 7b246ac2f000-7b246ac30000 rw-p 00008000 103:06 5909120 /home/william/swig/github/wsfulton/swig/Examples/test-suite/ruby/import_fragments.so 7b246ac30000-7b246ac80000 rw-p 00000000 00:00 0 7b246ac87000-7b246ad8d000 rw-p 00000000 00:00 0 7b246ad8d000-7b246ad9d000 r--p 00000000 103:04 408271 /usr/lib/x86_64-linux-gnu/libm.so.6 7b246ad9d000-7b246ae1c000 r-xp 00010000 103:04 408271 /usr/lib/x86_64-linux-gnu/libm.so.6 7b246ae1c000-7b246ae74000 r--p 0008f000 103:04 408271 /usr/lib/x86_64-linux-gnu/libm.so.6 7b246ae74000-7b246ae75000 r--p 000e7000 103:04 408271 /usr/lib/x86_64-linux-gnu/libm.so.6 7b246ae75000-7b246ae76000 rw-p 000e8000 103:04 408271 /usr/lib/x86_64-linux-gnu/libm.so.6 7b246ae76000-7b246ae78000 r--p 00000000 103:04 407962 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7b246ae78000-7b246ae8d000 r-xp 00002000 103:04 407962 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7b246ae8d000-7b246aea6000 r--p 00017000 103:04 407962 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7b246aea6000-7b246aea7000 r--p 0002f000 103:04 407962 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7b246aea7000-7b246aea8000 rw-p 00030000 103:04 407962 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7b246aea8000-7b246aeb0000 rw-p 00000000 00:00 0 7b246aeb0000-7b246aeba000 r--p 00000000 103:04 408107 /usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0 7b246aeba000-7b246af1d000 r-xp 0000a000 103:04 408107 /usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0 7b246af1d000-7b246af32000 r--p 0006d000 103:04 408107 /usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0 7b246af32000-7b246af33000 r--p 00081000 103:04 408107 /usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0 7b246af33000-7b246af34000 rw-p 00082000 103:04 408107 /usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0 7b246af34000-7b246af36000 r--p 00000000 103:04 408661 /usr/lib/x86_64-linux-gnu/libz.so.1.3 7b246af36000-7b246af48000 r-xp 00002000 103:04 408661 /usr/lib/x86_64-linux-gnu/libz.so.1.3 7b246af48000-7b246af4e000 r--p 00014000 103:04 408661 /usr/lib/x86_64-linux-gnu/libz.so.1.3 7b246af4e000-7b246af4f000 r--p 0001a000 103:04 408661 /usr/lib/x86_64-linux-gnu/libz.so.1.3 7b246af4f000-7b246af50000 rw-p 0001b000 103:04 408661 /usr/lib/x86_64-linux-gnu/libz.so.1.3 7b246af56000-7b246af57000 r--p 00000000 103:06 30823100 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/monitor.so 7b246af57000-7b246af58000 r-xp 00001000 103:06 30823100 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/monitor.so 7b246af58000-7b246af59000 r--p 00002000 103:06 30823100 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/monitor.so 7b246af59000-7b246af5a000 r--p 00002000 103:06 30823100 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/monitor.so 7b246af5a000-7b246af5b000 rw-p 00003000 103:06 30823100 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/monitor.so 7b246af5b000-7b246af5c000 r--p 00000000 103:06 31620633 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/enc/trans/transdb.so 7b246af5c000-7b246af5e000 r-xp 00001000 103:06 31620633 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/enc/trans/transdb.so 7b246af5e000-7b246af5f000 r--p 00003000 103:06 31620633 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/enc/trans/transdb.so 7b246af5f000-7b246af60000 r--p 00003000 103:06 31620633 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/enc/trans/transdb.so 7b246af60000-7b246af61000 rw-p 00004000 103:06 31620633 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/enc/trans/transdb.so 7b246af61000-7b246af62000 r--p 00000000 103:06 30818979 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/enc/encdb.so 7b246af62000-7b246af64000 r-xp 00001000 103:06 30818979 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/enc/encdb.so 7b246af64000-7b246af65000 r--p 00003000 103:06 30818979 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/enc/encdb.so 7b246af65000-7b246af66000 r--p 00003000 103:06 30818979 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/enc/encdb.so 7b246af66000-7b246af67000 rw-p 00004000 103:06 30818979 /home/william/install/ruby-3_2_3-debug/lib/ruby/3.2.0/x86_64-linux/enc/encdb.so 7b246af67000-7b246af6e000 r--s 00000000 103:04 409682 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache 7b246af6e000-7b246af70000 rw-p 00000000 00:00 0 7b246af70000-7b246af74000 r--p 00000000 00:00 0 [vvar] 7b246af74000-7b246af76000 r-xp 00000000 00:00 0 [vdso] 7b246af76000-7b246af77000 r--p 00000000 103:04 407739 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7b246af77000-7b246afa2000 r-xp 00001000 103:04 407739 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7b246afa2000-7b246afac000 r--p 0002c000 103:04 407739 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7b246afac000-7b246afae000 r--p 00036000 103:04 407739 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7b246afae000-7b246afb0000 rw-p 00038000 103:04 407739 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7ffdcf987000-7ffdd0186000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] Aborted (core dumped) make: *** [Makefile:82: import_fragments.cpptest] Error 134 2. Using attached tarball 2a. tar -xf ruby-crash-.tar.bz2 2b. cd ruby-crash 2c. Adjust RUBY_ROOT in Makefile to your Ruby installation 2c. make ---Files-------------------------------- ruby-crash.tar.bz2 (21 KB) -- https://bugs.ruby-lang.org/

2 4

[ruby-core:121699] [Ruby Feature#21277] Windows ARM support
by hsbt (Hiroshi SHIBATA) 21 Apr '25

21 Apr '25

Issue #21277 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21277: Windows ARM support https://bugs.ruby-lang.org/issues/21277 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I added the new CI job for Windows ARM support. * https://github.blog/changelog/2025-04-14-windows-arm64-hosted-runners-now-a… * https://github.com/ruby/ruby/pull/13118 We could build Ruby with Windows ARM platform. But `nmake check` is not working yet. I'm tracking that issues on this ticket. ## Can't generate `revision.h` `windows-11-arm` runner couldn't generate `revision.h` with `ruby tool/file2lastrev.rb --revision.h --output=revision.h`. I tried that with git provided by `scoop`. But that is also not working. I confirmed to work `git rev-parse HEAD` directly with `pwsh` of GitHub Actions. But `tool/file2lastrev.rb` returns the followings: ``` Run ruby tool/file2lastrev.rb --revision.h --output=revision.h file2lastrev.rb: git rev-parse failed fatal: unable to access 'NUL': Invalid argument ``` ## `nmake check` is not working https://github.com/ruby/ruby/actions/runs/14564201209/job/40851166866 ``` running file: C:/a/ruby/ruby/src/test/rubygems/test_gem_resolver_index_set.rb A test worker crashed. It might be an interpreter bug or a bug in test/unit/parallel.rb. Try again without the -j option. ``` https://github.com/ruby/ruby/actions/runs/14564667517/job/40852193517 ``` NMAKE : fatal error U1077: '@ .\ruby.exe -I../src/lib -I".ext/arm64-mswin64_140" -I. "../src/tool/runruby.rb" --extout=".ext" -- --disable-gems -r./arm64-mswin64_140-fake -r../src/tool/lib/_tmpdir ../src/spec/mspec/bin/mspec run -B ../src/spec/default.mspec ' : return code '0xc0000005' Stop. ``` They may be caused by Visual Studio 2022 issue same as #21255. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121698] [Ruby Feature#3388] regexp support for start_with? and end_with?
by Eregon (Benoit Daloze) 21 Apr '25

21 Apr '25

Issue #3388 has been updated by Eregon (Benoit Daloze). `end_with?(/regex/)` if it recreates a Regexp on every call would be extremely slow. Languages with such APIs have learned the hard way it's a mistake to expose such APIs creating a Regexp behind the scenes. One thing that could work is to lazily create and cache inside a Regexp object a variant of it with \z for this purpose. But it would likely increase footprint. ---------------------------------------- Feature #3388: regexp support for start_with? and end_with? https://bugs.ruby-lang.org/issues/3388#change-112750 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: naruse (Yui NARUSE) ---------------------------------------- =begin ruby-1.9.2-head > "aBcdeFghIj".start_with?(/abc/i) => false In my implementation of start_with? it is easy enough to utilize #index, which works fine: def start_with?(pattern) index(pattern) == 0 end But #end_with? is more difficult, and I had to use regular expressions. def end_with?(suffix) suffix = Regexp.escape(suffix) if String===suffix /#{suffix}$/.match(self) ? true : false end However, we might get rid of the '? true : false' and return the MatchData, since that could be useful information. =end ---Files-------------------------------- 0001-string.c-rb_str_start_with-rb_str_end_with-allow-Reg.patch (4.08 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121413] [Ruby Bug#21193] Inherited callback returns `nil` for `Object.const_source_location`
by eileencodes (Eileen Uchitelle) 20 Apr '25

20 Apr '25

Issue #21193 has been reported by eileencodes (Eileen Uchitelle). ---------------------------------------- Bug #21193: Inherited callback returns `nil` for `Object.const_source_location` https://bugs.ruby-lang.org/issues/21193 * Author: eileencodes (Eileen Uchitelle) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Since https://github.com/ruby/ruby/pull/12927 the inherited callback no longer can access the `Object.const_source_location`. A simplified reproduction is the following: ```ruby class A def self.inherited(other) super p Object.const_source_location(other.name) end end class B < A end ``` Prior to this change `Object.const_source_location(other.name)` would return `["test.rb", 8]` and now returns `nil`. Shopify's application uses the `inherited` callback to load configuration classes and since it's unable to find these classes they aren't loaded when they are called. It's not clear if this was intended or if there's a workaround. In chatting with folks at GitHub, they have a similar issue (although that case sounds less straightforward). A more accurate example of what we have (I did strip this down a bunch too): ```ruby def self.inherited(config) return super unless config.superclass == Config if (class_name = config.name) && (config_location = Object.const_source_location(class_name)) && (parent_dirname = File.dirname(config_location[0])) config_dirname = File.join(parent_dirname, "config") config.autoload(:Something, File.join(config_dirname, "something.rb")) end super end ``` Original issue: https://bugs.ruby-lang.org/issues/21143 cc/ @byroot @fxn -- https://bugs.ruby-lang.org/

6 14

[ruby-core:121685] [Ruby Bug#21273] regression on 3.1.7 vs 3.1.2
by rouca (Bastien Roucaries) 20 Apr '25

20 Apr '25

Issue #21273 has been reported by rouca (Bastien Roucaries). ---------------------------------------- Bug #21273: regression on 3.1.7 vs 3.1.2 https://bugs.ruby-lang.org/issues/21273 * Author: rouca (Bastien Roucaries) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hi, On debian we wish to package the last 3.1 version before EOL unfortunaltly it regress see https://salsa.debian.org/ruby-team/ruby/-/jobs/7430073#L7376 We are clue less could we get some help ? -- https://bugs.ruby-lang.org/

2 4