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

[ruby-core:123207] [Ruby Bug#21568] Requiring core libraries when already requiring mutliple user defined libraries with the same name can error
by alexalexgriffith (Alex Griffith) 02 Oct '25

02 Oct '25

Issue #21568 has been reported by alexalexgriffith (Alex Griffith). ---------------------------------------- Bug #21568: Requiring core libraries when already requiring mutliple user defined libraries with the same name can error https://bugs.ruby-lang.org/issues/21568 * Author: alexalexgriffith (Alex Griffith) * Status: Open * ruby -v: ruby 3.1.7 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The simplest way to understand this error is that after requiring 2 or more files with the same name as some core libraries, any subsequent calls to require the core library will fail, ie ```ruby require '/Users/alex/foo/fiber' require '/Users/alex/bar/fiber' require 'fiber' ``` raises ``` cannot load such file -- fiber ``` More detailed instructions to repro this can be found in the code snippet below. Noting that I am on a Mac, OS 15.6. This is reproducible across my team on a few different OS versions, all Mac. The same underlying issue can also be seen in some other issues like: https://github.com/newrelic/newrelic-ruby-agent/issues/2001 The context this error is discovered in is that some gems may require their own libraries with the same name as core libraries, often wrapping the implementations of those core libraries to extend functionality, like the New Relic ruby agent does with fiber, for example (https://github.com/newrelic/newrelic-ruby-agent/tree/dev/lib/new_relic/agen…) Then, if 2 or more gems do something like that, and any other gem has `require 'fiber'` in it to support old ruby versions where this was necessary, the error occurs. **Full Steps to Reproduce:** ``` ruby # Setup # ===== # 1. Set this base_dir variable to be an absolute path to a dir # or something that can be found in your $LOAD_PATH. base_dir = # ex: "/Users/<you>/ruby_require_test" # 2. Within that base directory create 2 directories named `foo` and `bar` # 3. Within both `foo` and `bar` touch new files named # - complex.rb # - enumerator.rb # - fiber.rb # - rational.rb # - ruby2_keywords.rb # - set.rb # - thread.rb # Note - this list was generated by running: # `ruby -ve 'p $LOADED_FEATURES.reject { |feature| %r|/| =~ feature }'` # which returns: `["enumerator.so", "thread.rb", "fiber.so", "rational.so", "complex.so", "ruby2_keywords.rb"]` # Reproducing the error: # After requiring 2 (or more) user defined files with the same name as part of # the ruby core library that is required as a bare filename, requiring that part of # the core library will error, ex: `cannot load such file -- fiber`. # The erroring require statements are all .so files begin require "#{base_dir}/foo/complex" require "#{base_dir}/bar/complex" require 'complex' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/enumerator" require "#{base_dir}/bar/enumerator" require 'enumerator' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/fiber" require "#{base_dir}/bar/fiber" require 'fiber' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/rational" require "#{base_dir}/bar/rational" require 'rational' rescue LoadError => e puts e.message end # The following examples do not error. # The difference seems to be that the core lib files are defined as .rb not .so begin require "#{base_dir}/foo/ruby2_keywords" require "#{base_dir}/bar/ruby2_keywords" require 'ruby2_keywords' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/set" require "#{base_dir}/bar/set" require 'set' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/thread" require "#{base_dir}/bar/thread" require 'thread' rescue LoadError => e puts e.message end ``` -- https://bugs.ruby-lang.org/

3 6

[ruby-core:123375] [Ruby Bug#21622] Prism wrongly accepts command call to be a key of keyword argument
by tompng (tomoya ishida) 02 Oct '25

02 Oct '25

Issue #21622 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21622: Prism wrongly accepts command call to be a key of keyword argument https://bugs.ruby-lang.org/issues/21622 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-02T03:48:32Z master 88222caaa9) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- These are syntax error in parse.y but accepted in Prism ~~~ruby p(p a, x: b => value) p(p a, x: => value) p(p a, &block => value) p(p a, *args => value) p(p a, **kwargs => value) ~~~ Maybe as a result, Prism accepts command call within command call ~~~ruby p p 1, &block => 2, &block p p p 1 => 2 => 3 => 4 ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123350] [Ruby Bug#21618] Allow to use the build-in prism version to parse code
by Earlopain (Earlopain _) 02 Oct '25

02 Oct '25

Issue #21618 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21618: Allow to use the build-in prism version to parse code https://bugs.ruby-lang.org/issues/21618 * Author: Earlopain (Earlopain _) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Prism is a multi-version parser, which is a great feature. If one calls `Prism.parse("foo")`, it will always use the latest version prism knows about. This may or may not be the version that is currently executing. This is problematic when one wants to introspect code the same way that the currently running ruby version would. Consider that some syntax will be disallowed in the next ruby version. I would have to specify the ruby version I want to parse as in order to not run into syntax errors: `Prism.parse("foo", version: RUBY_VERSION)`. But doing so is not feasable because `prism` is distributed out of sync with ruby itself. If the user already has prism in their lockfile, the user may run a prism version that doesn't yet know about lets say ruby 4.0 and thus raise. Similarly, it may parse as an older patch version that has subtle behaviour differences. `ripper` does not have this issue because it is always tied to the ruby version and it is not distributed as a gem, so what the user has will always be exactly what ruby shipped with. I wish for a similar API that utilizes the prism version bundled with ruby itself. Libraries like `rails` have moved from ripper to prism because of its superior developer experience but it risks breaking in unexpected ways with new `prism` versions that know about more recent syntax. `error_highlight` for example also suffers from the same defect. It seems like prism currently has 34 methods that optionally take a version (per the rbi file). Many of these are trivial helper methods like `Prism.parse_success?` (does the parse result have any errors?). I would be happy with supporting only the minimal functions like `Prism.parse` and `Prism.parse_file`. Currently I don't have a use-case for any of the other methods. Pretty much just functions to mirror `RubyVM::InstructionSequence.compile_file` and `RubyVM::InstructionSequence.compile`. It would be optimal if I would be able to transparently call `Prism.parse("foo", version: "current")` (or maybe even have an unspecified version mean the build-in prism version) but I am not sure how feasable that is since I'm pretty sure logic for this would have to live in ruby itself. @kddnewton does this feature request make sense? Do you have any other ideas/inputs? -- https://bugs.ruby-lang.org/

4 7

[ruby-core:123360] [Ruby Bug#21620] master branch: LTO with >= -O2 optimization causes miniruby to segfault in vm_cc
by jprokop (Jarek Prokop) 02 Oct '25

02 Oct '25

Issue #21620 has been reported by jprokop (Jarek Prokop). ---------------------------------------- Bug #21620: master branch: LTO with >= -O2 optimization causes miniruby to segfault in vm_cc https://bugs.ruby-lang.org/issues/21620 * Author: jprokop (Jarek Prokop) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ruby built with LTO (`-flto`) with the -O2 or -O3 optimization causes misbehavior in miniruby. Using -O1 does not result in segfault. Higher optimization is required. Removing `-flto` results in no segfault. Preview1 was OK, after running git-bisect I arrived at the following commit hash: [547f111b5b0d773af2a4268fe407fdacc7060109](https://github.com/ruby/ruby/comm… as the culprit that introduced the buggy behavior. Latest tested commit [3361aa5c7df35b1d1daea578fefec3addf29c9a6](https://github.com/ruby/ruby/comm… still exhibits this behavior. ``` $ export CFLAGS='-O2 -flto -g' $ ./autogen.sh $ ./configure $ ./make -j16 V=1 <...snip...> ./miniruby -I./lib -I. -I.ext/common ./tool/generic_erb.rb -o builtin_binary.rbbin \ ./template/builtin_binary.rbbin.tmpl make: *** [uncommon.mk:1363: builtin_binary.rbbin] Segmentation fault (core dumped) ``` Supplied also -g to have debug info available in GDB Once miniruby is linked and available to run, simplest reproducer is just `./miniruby`, that is enough for a segfault. This segfault was observed with following GCC versions as delivered on Fedora/RHEL: * Fedora 42: 15.2.1 * RHEL 10: 14.3.1 * RHEL 9: 11.5.0 There are different backtraces with different `O` optimization levels. The following backtraces are from the mentioned commit `547f111b5b0d773af2a4268fe407fdacc7060109` With -O2 ``` $ gdb ./miniruby (gdb) run Starting program: /home/fedora/projects/ruby/miniruby [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. vm_lookup_cc (klass=klass@entry=140737348630880, ci=ci@entry=0x7fffffffe450, mid=mid@entry=4161) at /home/fedora/projects/ruby/vm_insnhelper.c:2173 2173 const int ccs_len = ccs->len; (gdb) bt f #0 vm_lookup_cc (klass=klass@entry=140737348630880, ci=ci@entry=0x7fffffffe450, mid=mid@entry=4161) at /home/fedora/projects/ruby/vm_insnhelper.c:2173 ccs_len = 1 vm_locking_level = <optimized out> vm_locking_do = <optimized out> flag = <optimized out> i = <optimized out> ccs_ci_flag = <optimized out> ccs_cc = <optimized out> argc = <optimized out> ccs_ci_argc = <optimized out> cc_tbl = 140737348956800 ccs = 0x555555b88aa0 #1 0x00005555557bc6d6 in vm_search_cc (klass=140737348630880, ci=0x7fffffffe450) at /home/fedora/projects/ruby/vm_insnhelper.c:2220 mid = 4161 cc = <optimized out> #2 0x00005555557cf48e in rb_vm_search_method_slowpath (ci=<optimized out>, klass=<optimized out>) at /home/fedora/projects/ruby/vm_insnhelper.c:2247 cc = <optimized out> #3 vm_search_method_slowpath0 (cd_owner=0, cd=<synthetic pointer>, klass=<optimized out>) at /home/fedora/projects/ruby/vm_insnhelper.c:2266 cc = <optimized out> empty_cc = <optimized out> cc = <optimized out> empty_cc = <optimized out> #4 gccct_method_search_slowpath (vm=0x555555b6d310, klass=<optimized out>, index=200, ci=<optimized out>) at /home/fedora/projects/ruby/vm_eval.c:418 cd = <optimized out> #5 0x00005555557d899a in gccct_method_search (ec=0x555555b74390, recv=140737348632000, mid=4161, ci=0x7fffffffe450) at /home/fedora/projects/ruby/vm_eval.c:490 cc = <optimized out> klass = <optimized out> ns_value = <optimized out> ns = <optimized out> index = <optimized out> vm = <optimized out> klass = <optimized out> ns_value = <optimized out> ns = <optimized out> index = <optimized out> vm = <optimized out> cc = <optimized out> cme = <optimized out> #6 rb_funcallv_scope (recv=140737348632000, mid=4161, argc=<optimized out>, argv=0x7fffffffe538, scope=CALL_FCALL) at /home/fedora/projects/ruby/vm_eval.c:1059 ec = 0x555555b74390 ci = {flags = 106522, kwarg = 0x0, mid = 4161, flag = 4, argc = 1} cc = <optimized out> self = <optimized out> #7 0x000055555558fc50 in rb_funcallv (recv=140737348632000, mid=<optimized out>, argc=1, argv=0x7fffffffe538) at /home/fedora/projects/ruby/vm_eval.c:1080 No locals. #8 rb_class_inherited (super=super@entry=140737348632000, klass=klass@entry=140737348629120) at /home/fedora/projects/ruby/class.c:1472 rb_funcall_argc = 1 rb_funcall_args = {140737348629120} rb_funcall_nargs = 1 inherited = <optimized out> rbimpl_id = 4161 #9 0x000055555558fd6a in rb_define_class (name=<optimized out>, super=140737348632000) at /home/fedora/projects/ruby/class.c:1506 klass = 140737348629120 id = 5163 ns = <optimized out> #10 0x00005555556af895 in InitVM_Object () at /home/fedora/projects/ruby/object.c:4606 No locals. #11 0x00005555556498ff in Init_Object () at /home/fedora/projects/ruby/object.c:4639 No locals. #12 rb_call_inits () at /home/fedora/projects/ruby/inits.c:29 No locals. #13 0x0000555555613e10 in ruby_setup () at /home/fedora/projects/ruby/eval.c:87 _ec = 0x555555b74390 _tag = {tag = 36, retval = 3, buf = {0x7fffffffe948, 0x5555556132f8 <ruby_setup+872>, 0x7fffffffe6c0, 0x8800, 0x0}, prev = 0x0, state = RUBY_TAG_NONE, lock_rec = 0} state = RUBY_TAG_NONE #14 0x0000555555613fa9 in ruby_init () at /home/fedora/projects/ruby/eval.c:99 state = <optimized out> ec = <optimized out> #15 0x00005555555689e2 in rb_main (argc=1, argv=0x7fffffffe948) at ./main.c:41 variable_in_this_stack_frame = 0 #16 main (argc=<optimized out>, argv=<optimized out>) at ./main.c:62 No locals. ``` With -O3, there it fails at different point, so backtrace is different, for completeness this was configured with `export CFLAGS="-O3 -flto -g"`: ``` (gdb) run Starting program: /home/fedora/projects/ruby/miniruby [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7fffde5ff6c0 (LWP 519565)] Thread 1 "miniruby" received signal SIGSEGV, Segmentation fault. vm_ccs_push (cc_tbl=140737348956800, ccs=0x555555cc6ae0, ci=0x7fffffffd090, cc=0x7ffff7a7ea28) at /home/fedora/projects/ruby/vm_insnhelper.c:2006 2006 if (UNLIKELY(ccs->len == ccs->capa)) { Missing rpms, try: dnf --enablerepo='*debug*' install libxcrypt-debuginfo-4.4.38-7.fc41.x86_64 glibc-debuginfo-2.40-28.fc41.x86_64 libgcc-debuginfo-14.3.1-3.fc41.x86_64 (gdb) bt f #0 vm_ccs_push (cc_tbl=140737348956800, ccs=0x555555cc6ae0, ci=0x7fffffffd090, cc=0x7ffff7a7ea28) at /home/fedora/projects/ruby/vm_insnhelper.c:2006 pos = <optimized out> pos = <optimized out> #1 vm_populate_cc (klass=140737348630880, ci=0x7fffffffd090, mid=<optimized out>) at /home/fedora/projects/ruby/vm_insnhelper.c:2146 original_cc_table = 140737348956800 ccs = 0x555555cc6ae0 cme = 0x7ffff7acd128 cc = 0x7ffff7a7ea28 cc_tbl = 140737348956800 cc_tbl = <optimized out> original_cc_table = <optimized out> ccs = <optimized out> cme = <optimized out> cc = <optimized out> #2 vm_search_cc (klass=140737348630880, ci=0x7fffffffd090) at /home/fedora/projects/ruby/vm_insnhelper.c:2233 vm_locking_level = 21845 vm_locking_do = <optimized out> mid = <optimized out> cc = <optimized out> #3 0x000055555583508e in rb_vm_search_method_slowpath (ci=<optimized out>, klass=<optimized out>) at /home/fedora/projects/ruby/vm_insnhelper.c:2247 cc = <optimized out> #4 vm_search_method_slowpath0 (cd_owner=140737348407160, cd=<synthetic pointer>, klass=<optimized out>) at /home/fedora/projects/ruby/vm_insnhelper.c:2266 cc = <optimized out> empty_cc = <optimized out> cc = <optimized out> empty_cc = <optimized out> #5 gccct_method_search_slowpath (vm=0x555555bee310, klass=<optimized out>, index=377, ci=<optimized out>) at /home/fedora/projects/ruby/vm_eval.c:418 cd = <optimized out> #6 0x00005555558cf0fd in gccct_method_search (ec=0x555555bf5390, recv=140737348632000, mid=2865, ci=0x7fffffffd090) at /home/fedora/projects/ruby/vm_eval.c:490 cc = <optimized out> klass = <optimized out> ns_value = <optimized out> ns = <optimized out> index = <optimized out> vm = <optimized out> klass = <optimized out> ns_value = <optimized out> ns = <optimized out> index = <optimized out> vm = <optimized out> cc = <optimized out> cme = <optimized out> #7 rb_funcallv_scope.constprop.0 (recv=140737348632000, mid=2865, argc=1, argv=0x7fffffffd108, scope=CALL_FCALL) at /home/fedora/projects/ruby/vm_eval.c:1059 ec = 0x555555bf5390 ci = {flags = 106522, kwarg = 0x0, mid = 2865, flag = 4, argc = 1} cc = <optimized out> self = <optimized out> #8 0x0000555555816885 in rb_funcallv (argc=1, recv=140737348632000, mid=2865, argv=0x7fffffffd108) at /home/fedora/projects/ruby/vm_eval.c:1076 No locals. #9 const_added (klass=140737348632000, const_name=30875) at /home/fedora/projects/ruby/variable.c:4000 name = 7904012 #10 const_added (klass=140737348632000, const_name=30875) at /home/fedora/projects/ruby/variable.c:3996 name = <optimized out> #11 rb_const_set (klass=140737348632000, id=30875, val=140737348364880) at /home/fedora/projects/ruby/variable.c:4074 No locals. #12 rb_define_const (klass=140737348632000, name=name@entry=0x555555aff318 "RUBY_DESCRIPTION", val=val@entry=140737348364880) at /home/fedora/projects/ruby/variable.c:4176 id = 30875 #13 0x00005555558169ec in rb_define_global_const (name=0x555555aff318 "RUBY_DESCRIPTION", val=140737348364880) at /home/fedora/projects/ruby/variable.c:4180 No locals. #14 define_ruby_const (mod=140737348467520, name=0x555555aff318 "RUBY_DESCRIPTION", value=140737348364880, toplevel=true) at /home/fedora/projects/ruby/version.c:103 No locals. #15 define_ruby_description (jit_opt=<optimized out>) at /home/fedora/projects/ruby/version.c:243 n = 76 mRuby = 140737348467520 description = 140737348364880 desc = "ruby 3.5.0dev (2025-08-01T08:42:04Z master 547f111b5b) +PRISM [x86_64-linux]\000\000\000\000\000\000\000\000\000\000" #16 0x0000555555783cac in Init_ruby_description (opt=0x8) at /home/fedora/projects/ruby/version.c:253 jit_opt = <optimized out> jit_opt = <optimized out> #17 process_options (argc=<optimized out>, argc@entry=1, argv=<optimized out>, argv@entry=0x7fffffffe948, opt=opt@entry=0x7fffffffe680) at /home/fedora/projects/ruby/ruby.c:2378 ast_value = 4 result = {ast = 0x0, prism = {parser = {node_id = 0, lex_state = PM_LEX_STATE_NONE, enclosure_nesting = 0, lambda_enclosure_nesting = 0, brace_nesting = 0, do_loop_stack = 0, accepts_block_stack = 0, lex_modes = {current = 0x0, stack = {{mode = PM_LEX_DEFAULT, as = {list = {nesting = 0, interpolation = false, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000\000\000\000\000"}, regexp = {nesting = 0, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000"}, string = {nesting = 0, interpolation = false, label_allowed = false, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000"}, heredoc = {base = {ident_start = 0x0, ident_length = 0, quote = PM_HEREDOC_QUOTE_NONE, indent = PM_HEREDOC_INDENT_NONE}, next_start = 0x0, common_whitespace = 0x0, line_continuation = false}}, prev = 0x0}, {mode = PM_LEX_DEFAULT, as = {list = {nesting = 0, interpolation = false, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000\000\000\000\000"}, regexp = {nesting = 0, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000"}, string = {nesting = 0, --Type <RET> for more, q to quit, c to continue without paging-- interpolation = false, label_allowed = false, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000"}, heredoc = {base = {ident_start = 0x0, ident_length = 0, quote = PM_HEREDOC_QUOTE_NONE, indent = PM_HEREDOC_INDENT_NONE}, next_start = 0x0, common_whitespace = 0x0, line_continuation = false}}, prev = 0x0}, {mode = PM_LEX_DEFAULT, as = {list = {nesting = 0, interpolation = false, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000\000\000\000\000"}, regexp = {nesting = 0, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000"}, string = {nesting = 0, interpolation = false, label_allowed = false, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000"}, heredoc = {base = {ident_start = 0x0, ident_length = 0, quote = PM_HEREDOC_QUOTE_NONE, indent = PM_HEREDOC_INDENT_NONE}, next_start = 0x0, common_whitespace = 0x0, line_continuation = false}}, prev = 0x0}, {mode = PM_LEX_DEFAULT, as = {list = {nesting = 0, interpolation = false, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000\000\000\000\000"}, regexp = {nesting = 0, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000"}, string = {nesting = 0, interpolation = false, label_allowed = false, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000"}, heredoc = {base = {ident_start = 0x0, ident_length = 0, quote = PM_HEREDOC_QUOTE_NONE, indent = PM_HEREDOC_INDENT_NONE}, next_start = 0x0, common_whitespace = 0x0, line_continuation = false}}, prev = 0x0}}, index = 0}, start = 0x0, end = 0x0, previous = {type = 0, start = 0x0, end = 0x0}, current = {type = 0, start = 0x0, end = 0x0}, next_start = 0x0, heredoc_end = 0x0, comment_list = {size = 0, head = 0x0, tail = 0x0}, magic_comment_list = {size = 0, head = 0x0, tail = 0x0}, data_loc = {start = 0x0, end = 0x0}, warning_list = {size = 0, head = 0x0, tail = 0x0}, error_list = {size = 0, head = 0x0, tail = 0x0}, current_scope = 0x0, current_context = 0x0, current_hash_keys = 0x0, encoding = 0x0, encoding_changed_callback = 0x0, encoding_comment_start = 0x0, lex_callback = 0x0, filepath = {source = 0x0, length = 0, type = PM_STRING_CONSTANT}, constant_pool = {buckets = 0x0, constants = 0x0, size = 0, capacity = 0}, newline_list = {start = 0x0, size = 0, capacity = 0, offsets = 0x0}, integer_base = 0, current_string = {source = 0x0, length = 0, type = PM_STRING_CONSTANT}, start_line = 0, explicit_encoding = 0x0, current_block_exits = 0x0, version = PM_OPTIONS_VERSION_UNSET, command_line = 0 '\000', frozen_string_literal = 0 '\000', parsing_eval = false, partial_script = false, command_start = false, recovering = false, encoding_locked = false, encoding_changed = false, pattern_matching_newlines = false, in_keyword_arg = false, semantic_token_seen = false, current_regular_expression_ascii_only = false, warn_mismatched_indentation = false}, options = {shebang_callback = 0x0, shebang_callback_data = 0x0, filepath = { source = 0x0, length = 0, type = PM_STRING_CONSTANT}, line = 0, encoding = {source = 0x0, length = 0, type = PM_STRING_CONSTANT}, scopes_count = 0, scopes = 0x0, version = PM_OPTIONS_VERSION_UNSET, command_line = 0 '\000', frozen_string_literal = 0 '\000', encoding_locked = false, main_script = false, partial_script = false, freeze = false}, input = {source = 0x0, length = 0, type = PM_STRING_CONSTANT}, node = {base = {type = 0, flags = 0, node_id = 0, location = { start = 0x0, end = 0x0}}, previous = 0x0, ast_node = 0x0, parameters = 0x0, body = 0x0, locals = {size = 0, capacity = 0, ids = 0x0}, parser = 0x0, encoding = 0x0, script_lines = 0x0, filepath_encoding = 0x0, local_table_for_iseq_size = 0, constants = 0x0, index_lookup_table = 0x0, coverage_enabled = 0, pre_execution_anchor = 0x0}, parsed = false}} iseq = <optimized out> enc = <optimized out> lenc = <optimized out> s = <optimized out> fbuf = "\300\317\033\000\000\000\000\000\000\004\000\000\000\000\000\000\260\327\377\377\377\177\000\000\030\022\337\367\377\177\000\000\020\327\373\367\377\177\000\000|\353\336\367\377\177\000\000\201\031\236|\000\000\000\000\020:\340\367\377\177\000\000p\327\377\377\377\177\000\000\033\002\375\367\377\177\000\000\257\002\000\000\000\000\000\000\020:\340\367\377\177\000\000\020\327\373\367\377\177\000\0008\327\377\377\377\177\000\0004\327\377\377\377\177\000\000\235\340\026\000\000\000\000\000\235\340\026\000\000\000\000\000\000\020\000\000\000\000\000\000\001\000\000\000\004\000\000\000\000\000\027\000\000\000\000\000\000\000\027", '\000' <repeats 13 times>, "\006\000\000\000\000\000\000\000(\335\373\367\377\177\000\000\030\330\377\377\377\177\000\000"... i = <optimized out> dump = <optimized out> vm = 0x555555bee310 loaded_before_enc = 8 rbimpl_id = 0 #18 0x000055555578604d in ruby_process_options (argc=1, argv=0x7fffffffe948) at /home/fedora/projects/ruby/ruby.c:222 opt = {script = 0x0, script_name = 0, e_script = 0, src = {enc = {name = 0, index = -1}}, ext = {enc = {name = 0, index = -1}}, intern = {enc = {name = 0, index = -1}}, req_list = 0, features = {mask = 0, set = 31}, warn = {mask = 0, set = 0}, dump = 8, backtrace_length_limit = -9223372036854775808, crash_report = 0x0, sflag = 0, xflag = 0, warning = 0, verbose = 0, do_loop = 0, do_print = 0, do_line = 0, do_split = 0, do_search = 0, setids = 0, yjit = 0} iseq = <optimized out> script_name = <optimized out> #19 0x0000555555628844 in ruby_options (argc=<optimized out>, argv=<optimized out>) at /home/fedora/projects/ruby/eval.c:118 _ec = 0x555555bf5390 _tag = {tag = 36, retval = 34816, buf = {0x7fffffffe948, 0x55555562886a <ruby_options+186>, 0x7fffffffe740, 0x68dd1020, 0x0}, prev = 0x0, state = RUBY_TAG_NONE, lock_rec = 0} ec = 0x555555bf5390 state = RUBY_TAG_NONE iseq = 0x0 #20 0x0000555555569d2c in rb_main (argc=1, argv=0x7fffffffe948) at ./main.c:42 variable_in_this_stack_frame = 0 #21 main (argc=<optimized out>, argv=<optimized out>) at ./main.c:62 ``` This time there is also Ruby's segfault handler, with -O2 it doesn't reach that stage: ``` $ ./miniruby ./miniruby: [BUG] Segmentation fault at 0x0000000000000004 ruby 3.5.0dev (2025-08-01T08:42:04Z master 547f111b5b) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0001 p:0000 s:0003 E:001460 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x000055609bc1cb7c RBP: 0x0000000000000000 RSP: 0x00007ffda4c6ad10 RAX: 0x0000000000000000 RBX: 0x00007ffda4c6add0 RCX: 0x0000000000000000 RDX: 0x000000000000b01a RDI: 0x0000000000000000 RSI: 0x00007f729eb5e998 R8: 0x0000000000000000 R9: 0x00007f72a07fd130 R10: 0x0000000000000000 R11: 0x00007f729eb5e998 R12: 0x00007f72a07ef968 R13: 0x00007f729eb5e998 R14: 0x00007f72b9c4f288 R15: 0x0000000000000000 EFL: 0x0000000000010246 -- C level backtrace information ------------------------------------------- /home/fedora/projects/ruby/miniruby(0x55609bc515d5) [0x55609bc515d5] /home/fedora/projects/ruby/miniruby(0x55609bc556cf) [0x55609bc556cf] /home/fedora/projects/ruby/miniruby(0x55609ba2554c) [0x55609ba2554c] /home/fedora/projects/ruby/miniruby(0x55609bb9d462) [0x55609bb9d462] /lib64/libc.so.6(__restore_rt+0x0) [0x7f72b9dd8450] /home/fedora/projects/ruby/miniruby(0x55609bc1cb7c) [0x55609bc1cb7c] /home/fedora/projects/ruby/miniruby(0x55609bc3d08e) [0x55609bc3d08e] /home/fedora/projects/ruby/miniruby(0x55609bcd70fd) [0x55609bcd70fd] /home/fedora/projects/ruby/miniruby(0x55609bc1e885) [0x55609bc1e885] /home/fedora/projects/ruby/miniruby(0x55609bc1e9ec) [0x55609bc1e9ec] /home/fedora/projects/ruby/miniruby(0x55609bb8bcac) [0x55609bb8bcac] /home/fedora/projects/ruby/miniruby(0x55609bb8e04d) [0x55609bb8e04d] /home/fedora/projects/ruby/miniruby(0x55609ba30844) [0x55609ba30844] /home/fedora/projects/ruby/miniruby(0x55609b971d2c) [0x55609b971d2c] /lib64/libc.so.6(__libc_start_call_main+0x78) [0x7f72b9dc1448] /lib64/libc.so.6(__libc_start_main+0x8b) [0x7f72b9dc150b] [0x55609b971d65] -- Other runtime information ----------------------------------------------- * Loaded script: ./miniruby * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 pathname.so 6 ruby2_keywords.rb 7 set.rb * Process memory map: 55609b95c000-55609b95d000 r--p 00000000 00:26 193598 /home/fedora/projects/ruby/miniruby 55609b95d000-55609bdfa000 r-xp 00001000 00:26 193598 /home/fedora/projects/ruby/miniruby 55609bdfa000-55609bfc7000 r--p 0049e000 00:26 193598 /home/fedora/projects/ruby/miniruby 55609bfc7000-55609bfdd000 r--p 0066a000 00:26 193598 /home/fedora/projects/ruby/miniruby 55609bfdd000-55609bfdf000 rw-p 00680000 00:26 193598 /home/fedora/projects/ruby/miniruby 55609bfdf000-55609bff4000 rw-p 00000000 00:00 0 5560c4356000-5560c4449000 rw-p 00000000 00:00 0 [heap] 7f729b600000-7f729b858000 r--s 00000000 00:26 131829 /usr/lib64/libc.so.6 7f729ba00000-7f729ea29000 r--s 00000000 00:26 193598 /home/fedora/projects/ruby/miniruby 7f729eb50000-7f729eb60000 rw-p 00000000 00:00 0 7f729eb6f000-7f729eb70000 ---p 00000000 00:00 0 7f729eb70000-7f729ec11000 rw-p 00000000 00:00 0 7f729ec11000-7f729ec12000 ---p 00000000 00:00 0 7f729ec12000-7f729ecb3000 rw-p 00000000 00:00 0 7f729ecb3000-7f729ecb4000 ---p 00000000 00:00 0 7f729ecb4000-7f729ed55000 rw-p 00000000 00:00 0 7f729ed55000-7f729ed56000 ---p 00000000 00:00 0 7f729ed56000-7f729edf7000 rw-p 00000000 00:00 0 7f729edf7000-7f729edf8000 ---p 00000000 00:00 0 7f729edf8000-7f729ee99000 rw-p 00000000 00:00 0 7f729ee99000-7f729ee9a000 ---p 00000000 00:00 0 7f729ee9a000-7f729ef3b000 rw-p 00000000 00:00 0 7f729ef3b000-7f729ef3c000 ---p 00000000 00:00 0 7f729ef3c000-7f729efdd000 rw-p 00000000 00:00 0 7f729efdd000-7f729efde000 ---p 00000000 00:00 0 7f729efde000-7f729f07f000 rw-p 00000000 00:00 0 7f729f07f000-7f729f080000 ---p 00000000 00:00 0 7f729f080000-7f729f121000 rw-p 00000000 00:00 0 7f729f121000-7f729f122000 ---p 00000000 00:00 0 7f729f122000-7f729f1c3000 rw-p 00000000 00:00 0 7f729f1c3000-7f729f1c4000 ---p 00000000 00:00 0 7f729f1c4000-7f729f265000 rw-p 00000000 00:00 0 7f729f265000-7f729f266000 ---p 00000000 00:00 0 7f729f266000-7f729f307000 rw-p 00000000 00:00 0 7f729f307000-7f729f308000 ---p 00000000 00:00 0 7f729f308000-7f729f3a9000 rw-p 00000000 00:00 0 7f729f3a9000-7f729f3aa000 ---p 00000000 00:00 0 7f729f3aa000-7f729f44b000 rw-p 00000000 00:00 0 7f729f44b000-7f729f44c000 ---p 00000000 00:00 0 7f729f44c000-7f729f4ed000 rw-p 00000000 00:00 0 7f729f4ed000-7f729f4ee000 ---p 00000000 00:00 0 7f729f4ee000-7f729f58f000 rw-p 00000000 00:00 0 7f729f58f000-7f729f590000 ---p 00000000 00:00 0 7f729f590000-7f729f631000 rw-p 00000000 00:00 0 7f729f631000-7f729f632000 ---p 00000000 00:00 0 7f729f632000-7f729f6d3000 rw-p 00000000 00:00 0 7f729f6d3000-7f729f6d4000 ---p 00000000 00:00 0 7f729f6d4000-7f729f775000 rw-p 00000000 00:00 0 7f729f775000-7f729f776000 ---p 00000000 00:00 0 7f729f776000-7f729f817000 rw-p 00000000 00:00 0 7f729f817000-7f729f818000 ---p 00000000 00:00 0 7f729f818000-7f729f8b9000 rw-p 00000000 00:00 0 7f729f8b9000-7f729f8ba000 ---p 00000000 00:00 0 7f729f8ba000-7f729f95b000 rw-p 00000000 00:00 0 7f729f95b000-7f729f95c000 ---p 00000000 00:00 0 7f729f95c000-7f729f9fd000 rw-p 00000000 00:00 0 7f729f9fd000-7f729f9fe000 ---p 00000000 00:00 0 7f729f9fe000-7f729fa9f000 rw-p 00000000 00:00 0 7f729fa9f000-7f729faa0000 ---p 00000000 00:00 0 7f729faa0000-7f729fb41000 rw-p 00000000 00:00 0 7f729fb41000-7f729fb42000 ---p 00000000 00:00 0 7f729fb42000-7f729fbe3000 rw-p 00000000 00:00 0 7f729fbe3000-7f729fbe4000 ---p 00000000 00:00 0 7f729fbe4000-7f729fc85000 rw-p 00000000 00:00 0 7f729fc85000-7f729fc86000 ---p 00000000 00:00 0 7f729fc86000-7f729fd27000 rw-p 00000000 00:00 0 7f729fd27000-7f729fd28000 ---p 00000000 00:00 0 7f729fd28000-7f729fdc9000 rw-p 00000000 00:00 0 7f729fdc9000-7f729fdca000 ---p 00000000 00:00 0 7f729fdca000-7f729fe6b000 rw-p 00000000 00:00 0 7f729fe6b000-7f729fe6c000 ---p 00000000 00:00 0 7f729fe6c000-7f729ff0d000 rw-p 00000000 00:00 0 7f729ff0d000-7f729ff0e000 ---p 00000000 00:00 0 7f729ff0e000-7f729ffaf000 rw-p 00000000 00:00 0 7f729ffaf000-7f729ffb0000 ---p 00000000 00:00 0 7f729ffb0000-7f72a07b0000 rw-p 00000000 00:00 0 7f72a07b0000-7f72b9c00000 rw-p 00000000 00:00 0 7f72b9c1f000-7f72b9c50000 rw-p 00000000 00:00 0 7f72b9c58000-7f72b9d59000 rw-p 00000000 00:00 0 7f72b9d59000-7f72b9d60000 r--s 00000000 00:26 150886 /usr/lib64/gconv/gconv-modules.cache 7f72b9d60000-7f72b9db9000 r--p 00000000 00:26 131283 /usr/lib/locale/C.utf8/LC_CTYPE 7f72b9db9000-7f72b9dbe000 rw-p 00000000 00:00 0 7f72b9dbe000-7f72b9dbf000 r--p 00000000 00:26 131829 /usr/lib64/libc.so.6 7f72b9dbf000-7f72b9f2e000 r-xp 00001000 00:26 131829 /usr/lib64/libc.so.6 7f72b9f2e000-7f72b9fa3000 r--p 00170000 00:26 131829 /usr/lib64/libc.so.6 7f72b9fa3000-7f72b9fa7000 r--p 001e5000 00:26 131829 /usr/lib64/libc.so.6 7f72b9fa7000-7f72b9fa9000 rw-p 001e9000 00:26 131829 /usr/lib64/libc.so.6 7f72b9fa9000-7f72b9fb1000 rw-p 00000000 00:00 0 7f72b9fb1000-7f72b9fb2000 r--p 00000000 00:26 131249 /usr/lib64/libgcc_s-14-20250808.so.1 7f72b9fb2000-7f72b9fd6000 r-xp 00001000 00:26 131249 /usr/lib64/libgcc_s-14-20250808.so.1 7f72b9fd6000-7f72b9fde000 r--p 00025000 00:26 131249 /usr/lib64/libgcc_s-14-20250808.so.1 7f72b9fde000-7f72b9fdf000 r--p 0002c000 00:26 131249 /usr/lib64/libgcc_s-14-20250808.so.1 7f72b9fdf000-7f72b9fe0000 rw-p 00000000 00:00 0 7f72b9fe0000-7f72b9fe1000 r--p 00000000 00:26 131831 /usr/lib64/libm.so.6 7f72b9fe1000-7f72ba05a000 r-xp 00001000 00:26 131831 /usr/lib64/libm.so.6 7f72ba05a000-7f72ba0c4000 r--p 0007a000 00:26 131831 /usr/lib64/libm.so.6 7f72ba0c4000-7f72ba0c5000 r--p 000e3000 00:26 131831 /usr/lib64/libm.so.6 7f72ba0c5000-7f72ba0c6000 rw-p 000e4000 00:26 131831 /usr/lib64/libm.so.6 7f72ba0c6000-7f72ba0c7000 r--p 00000000 00:26 57774 /usr/lib64/libcrypt.so.2.0.0 7f72ba0c7000-7f72ba0e0000 r-xp 00001000 00:26 57774 /usr/lib64/libcrypt.so.2.0.0 7f72ba0e0000-7f72ba0fa000 r--p 0001a000 00:26 57774 /usr/lib64/libcrypt.so.2.0.0 7f72ba0fa000-7f72ba0fb000 r--p 00033000 00:26 57774 /usr/lib64/libcrypt.so.2.0.0 7f72ba0fb000-7f72ba0fc000 rw-p 00000000 00:00 0 7f72ba100000-7f72ba101000 rw-p 00000000 00:00 0 7f72ba101000-7f72ba102000 rw-p 00000000 00:00 0 7f72ba102000-7f72ba104000 rw-p 00000000 00:00 0 7f72ba104000-7f72ba108000 r--p 00000000 00:00 0 [vvar] 7f72ba108000-7f72ba10a000 r--p 00000000 00:00 0 [vvar_vclock] 7f72ba10a000-7f72ba10c000 r-xp 00000000 00:00 0 [vdso] 7f72ba10c000-7f72ba10d000 r--p 00000000 00:26 131826 /usr/lib64/ld-linux-x86-64.so.2 7f72ba10d000-7f72ba136000 r-xp 00001000 00:26 131826 /usr/lib64/ld-linux-x86-64.so.2 7f72ba136000-7f72ba141000 r--p 0002a000 00:26 131826 /usr/lib64/ld-linux-x86-64.so.2 7f72ba141000-7f72ba143000 r--p 00035000 00:26 131826 /usr/lib64/ld-linux-x86-64.so.2 7f72ba143000-7f72ba145000 rw-p 00037000 00:26 131826 /usr/lib64/ld-linux-x86-64.so.2 7ffda4c4c000-7ffda4c6d000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] Segmentation fault (core dumped) ``` Once it gets to the segfault, I can reproduce the line/lookup without causing more crashing and the values are available, not sure what's up or if it crashes on the correct line in the debugger. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121389] [Ruby Bug#21187] Strings concatenated with `\` getting frozen with literal hashes (PRISM only)
by LocoDelAssembly 01 Oct '25

01 Oct '25

Issue #21187 has been reported by LocoDelAssembly (Hernán Pereira). ---------------------------------------- Bug #21187: Strings concatenated with `\` getting frozen with literal hashes (PRISM only) https://bugs.ruby-lang.org/issues/21187 * Author: LocoDelAssembly (Hernán Pereira) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When the first elements of a literal hash are strings that are concatenated with `\`, those elements are flagged with `PM_NODE_FLAG_STATIC_LITERAL` and a special optimization that I believe was introduced in https://github.com/ruby/ruby/commit/8080de04be8e99e71309745822a9d436cc4ae37c causes the strings to be frozen. Reproduction === test.rb ``` a = { a: 'one' \ 'two', b: 'three' \ 'four', c: 'five', d: 'six' \ 'seven' } b = { a: 'one', b: 'two' \ 'three' } puts "a = #{a.map { |k,v| {k => v.frozen?} }}" puts "b = #{b.map { |k,v| {k => v.frozen?} }}" ``` With prism: ``` $ ruby test.rb a = [{a: true}, {b: true}, {c: false}, {d: false}] b = [{a: false}, {b: false}] ``` With parse.y: ``` $ ruby --parser=parse.y test.rb a = [{a: false}, {b: false}, {c: false}, {d: false}] b = [{a: false}, {b: false}] ``` (Notice `b` hash is unaffected in both parsers) Not sure if this is just part of undefined behavior or this is indeed a bug. Assigning a string concatenated with `\` to a variable doesn't make it frozen, to the best of my knowledge this seems to be hash-specific. -- https://bugs.ruby-lang.org/

6 8

[ruby-core:123257] [Ruby Misc#21606] DevMeeting-2025-10-23
by mame (Yusuke Endoh) 01 Oct '25

01 Oct '25

Issue #21606 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21606: DevMeeting-2025-10-23 https://bugs.ruby-lang.org/issues/21606 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/10/23 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2025/10/20. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:123362] [Ruby Bug#21621] test-bundled-gems.rb timeouts with csv gem on ci
by YO4 (Yoshinao Muramatsu) 01 Oct '25

01 Oct '25

Issue #21621 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21621: test-bundled-gems.rb timeouts with csv gem on ci https://bugs.ruby-lang.org/issues/21621 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Github Actions workflow ```Windows 2025/Visual C++ 2022 (test-bundled-gems)``` has a timeout issue for csv gem. That timeout seems to have been missed for months. The following was recorded in a successful test. ``` Testing the csv gem D:/a/ruby/ruby/build/ruby.exe -C D:/a/ruby/ruby/src/gems/src/csv D:/a/ruby/ruby/src/.bundle/bin/rake test Sending KILL signal ``` This should record a failure in the test for the csv gem. With git bisect, I found the first bad is f30f0f0a22bb5cf536b5ca551f3dfa5ebb745030. It was also reproduced locally when using the mingw compiler. But I couldn't discover any more about this issue. It is another issue that test-bundled-gems.rb correctly recognizes timeouts as failures. I created a [PR14695](https://github.com/ruby/ruby/pull/14695) for that. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123357] [Ruby Feature#21619] logger: Context API
by chucke (Tiago Cardoso) 01 Oct '25

01 Oct '25

Issue #21619 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Feature #21619: logger: Context API https://bugs.ruby-lang.org/issues/21619 * Author: chucke (Tiago Cardoso) * Status: Open ---------------------------------------- The logger gem is notoriously simple to use, but hard to extend. One can only observe a few of the gems that added tags / json / logstash formatting support to see the same functionality reimplemented in "same but different" ways. For example, `logstash-logger`, `semantic_logger`, or the `activesupport` tagged logger handle tagging in virtually the same way. sidekiq has a (IMO) convoluted API to add per-job context to log message, which somewhat works as long as one does not need per-fiber contexts. Several other "log as JSON" gems fight with the same issues to deliver something that works, and either heavily patch the `Logger` or `Logger::Formatter` or circumvent its usage altogether. The default formatter already supports per-message context, but that context is limited to a few "static" parameters (severity, current time, process id, progname) which are logged in the following manner: Logger.new(STDOUT).info("foo") #=> I, [2025-08-13T15:00:03.830782 #5374] INFO -- : foo There is currently no way to add more parameters, or (if necessary) override the existing ones. These patterns could be coalesced into the main logger gem in a way that extending it should be simpler than what it is right now. == Context API This is a proposal to extend the Logger API in a way that both per-scope or per-message context can be passed downstream to the formatter(s), and logged accordingly: logger = Logger.new(STDOUT) logger.info("foo") #=> I, [2025-08-13T15:00:03.830782 #5374] INFO -- : foo logger.info { "foo" } #=> I, [2025-08-13T15:00:03.830782 #5374] INFO -- : foo # per message context logger.info("foo", context: {user_id: 1}) #=> I, [user_id=1] [2025-08-13T15:00:03.830782 #5374] INFO -- : foo logger.info(context: { user_id: 1 }) { "foo" } #=> I, [user_id=1] [2025-08-13T15:00:03.830782 #5374] INFO -- : foo # or logger.info("foo", context: ["alwaysblue"]) #=> I, [alwaysblue] [2025-08-13T15:00:03.830782 #5374] INFO -- : foo. # per message context logger.with_context(a: 1) do logger.info("foo") #=> I, [a=1] [2025-08-13T15:00:03.830782 #5374] INFO -- : foo end logger.with_context(a: 1) do logger.with_context(b: 2) do logger.info("foo") #=> I, [a=1] [b=2] [2025-08-13T15:00:03.830782 #5374] INFO -- : foo end end This API would achieve the same goal as the examples mentioned above, or the sidekiq `Logger#with` function, in a standard manner, where formatters would just receive context as a bunch of key-value pairs (or an array of "string-able" objects, both work for me). == PR A proposal of the feature in logger can be found in https://github.com/ruby/logger/pull/132. It builds on top of the earlier addition of Logger#with_level, which does the scope-based change in a similar way, but only for the level, storing the context per fiber in the logger. Once context is standardized, adding i.e. a JSON or logstash formatter would be much simpler, formatters would receive it in the method call (instead of the indirection of using thread variables, which is what most mentioned implementations use). Drawbacks One of the main benefits of using the log.info { "msg" } idiom is that the "msg" string never gets allocated if the logger severity level skips logging the message. In the current proposal, the context is always present, and will result in a few allocations bubbling downstream. I'm not sure how important or negligible this concern is though. A concern here would be backwards compatibility, as currently, custom formatters do not expose a method signature which allows sending kwargs. Perhaps there's a way to introspect the formatter method to infer whether the signature supports kwargs, but even if it does, the check does have its cost. Other questions were raised during the PR review by jeremy evans and nevans. There's more discussion in the PR about pros and cons for each, so I'll just list them here: * supporting `with_context` block `:context` kwarg unnecessarily complex, proposal should stick to the former. * context should be stores in formatter rather than logger. * supporting hash and array as context in unnecessary complexity, pick the former * context log format should be like go, concatenated at the end of the message * extend formatter API to help users avoid leaking PII data -- https://bugs.ruby-lang.org/

2 1