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

[ruby-core:122615] [Ruby Misc#21458] Test 'make install'?
by MSP-Greg (Greg L) 22 Aug '25

22 Aug '25

Issue #21458 has been reported by MSP-Greg (Greg L). ---------------------------------------- Misc #21458: Test 'make install'? https://bugs.ruby-lang.org/issues/21458 * Author: MSP-Greg (Greg L) * Status: Open ---------------------------------------- Can `make install` be tested? Two items come to mind: 1. Test that all gems can be required? 2. Check that all gem binstubs are installed and work. Some of the above are being done in ruby-loco and https://github.com/ruby/ruby-dev-builder/blob/master/cli_test.rb. Both of these are cron jobs, they don't run on every commit. A long time ago, I think this was discussed, but it was back when CI was much more limited. It was also mixed in with the idea of running tests from the 'install' folder, rather than the 'build' folder. Maybe a few jobs could be added to check `make install` on the three main OS's (Ubuntu, macOS, Windows)? Lastly, with minimal changes, tests can be run from the install folder, which is what ruby-loco has done for years. Recently, two tests that I believe are skipped here started failing: ``` TestGemRequire#test_realworld_default_gem Line: 471 Expected "" to not be empty. TestGemRequire#test_realworld_upgraded_default_gem Line: 492 <"999.99.9"> expected but was <"/ruby/tmp/test_rubygems_20250628-8920-sifyoe/test_realworld_upgraded_default_gem.rb:3:in '<main>': undefined method 'version' for nil (NoMethodError)">. ``` -- https://bugs.ruby-lang.org/

6 9

[ruby-core:122964] [Ruby Feature#21543] Point ArgumentError to the call site
by mame (Yusuke Endoh) 22 Aug '25

22 Aug '25

Issue #21543 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #21543: Point ArgumentError to the call site https://bugs.ruby-lang.org/issues/21543 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- Consider this buggy code: ```ruby def foo(x, y) end foo(1) ``` The resulting error is: ``` $ ruby test.rb test.rb:1:in `foo': wrong number of arguments (given 1, expected 2) (ArgumentError) from test.rb:4:in `<main>' ``` I want this to be: ``` $ ruby test.rb test.rb:4:in `<main>': wrong number of arguments (given 1, expected 2) (ArgumentError) for `foo' at test.rb:1 ``` ## Problem In my experience, the code that needs fixing is almost always the caller, not the callee. In the above case, one would change `foo(1)` to something like `foo(1, 2)`. My typical debugging workflow starts with opening the first location shown in the backtrace. This takes me to the `def` line of the method. However, I can barely remember a single time I've ever had to fix the method definition itself in this scenario. I often find myself sighing, going back to the backtrace, finding the second location (the caller), and opening that file instead. I think this inconvenience is a significant loss of productivity. I understand that the current behavior is designed because developers need to check the callee (the method definition) to see what arguments are required for the fix. However, I believe the primary location in a backtrace should point to the code that is most likely to need modification. There are cases where developers can fix the call site without re-checking the method definition. Even when they do need to check the callee to recall the expected arguments, it feels more natural to first understand "what arguments am I currently passing?" at the call site before asking "what arguments should I be passing?". This workflow makes it easier to spot the mistake. ## Proposal I propose that the backtrace for an ArgumentError should point to the caller's location (the call site) as shown in the above. The location of the callee (the method definition) could instead be included within the error message itself. For a longer backtrace, the output would look like this: ```ruby class TestClass def foo(x, y) end def bar foo(1) end def main bar end end TestClass.new.main ``` ``` $ ruby test.rb test.rb:6:in 'TestClass#bar': wrong number of arguments (given 1, expected 2) (ArgumentError) for TestClass#foo at test.rb:2 from test.rb:10:in 'TestClass#main' from test.rb:14:in '<main>' ``` What do you think of this proposal? I have attached a proof-of-concept patch, though it will require more work before it is merge-ready. ```diff diff --git a/vm_args.c b/vm_args.c index 44be6f54c5..986cb3e4c1 100644 --- a/vm_args.c +++ b/vm_args.c @@ -980,17 +980,7 @@ raise_argument_error(rb_execution_context_t *ec, const rb_iseq_t *iseq, const rb { VALUE at; - if (iseq) { - vm_push_frame(ec, iseq, VM_FRAME_MAGIC_DUMMY | VM_ENV_FLAG_LOCAL, Qnil /* self */, - VM_BLOCK_HANDLER_NONE /* specval*/, (VALUE) cme /* me or cref */, - ISEQ_BODY(iseq)->iseq_encoded, - ec->cfp->sp, 0, 0 /* stack_max */); - at = rb_ec_backtrace_object(ec); - rb_vm_pop_frame(ec); - } - else { - at = rb_ec_backtrace_object(ec); - } + at = rb_ec_backtrace_object(ec); rb_ivar_set(exc, idBt_locations, at); rb_exc_set_backtrace(exc, at); @@ -1000,7 +990,15 @@ raise_argument_error(rb_execution_context_t *ec, const rb_iseq_t *iseq, const rb static void argument_arity_error(rb_execution_context_t *ec, const rb_iseq_t *iseq, const rb_callable_method_entry_t *cme, const int miss_argc, const int min_argc, const int max_argc) { - VALUE exc = rb_arity_error_new(miss_argc, min_argc, max_argc); + VALUE rb_gen_method_name(VALUE owner, VALUE name); + VALUE mname = rb_gen_method_name(cme->owner, rb_id2str(cme->def->original_id)); + const rb_iseq_t *miseq = cme->def->body.iseq.iseqptr; + VALUE file = Qfalse, lineno = 0; + if (miseq) { + file = rb_iseq_path(miseq); + lineno = rb_iseq_first_lineno(miseq); + } + VALUE exc = rb_arity_error_new(miss_argc, min_argc, max_argc, mname, file, lineno); if (ISEQ_BODY(iseq)->param.flags.has_kw) { const struct rb_iseq_param_keyword *const kw = ISEQ_BODY(iseq)->param.keyword; const ID *keywords = kw->table; diff --git a/vm_insnhelper.c b/vm_insnhelper.c index 3aca1bc24f..a5ad2f0562 100644 --- a/vm_insnhelper.c +++ b/vm_insnhelper.c @@ -484,7 +484,7 @@ rb_vm_push_frame_fname(rb_execution_context_t *ec, VALUE fname) /* method dispatch */ static inline VALUE -rb_arity_error_new(int argc, int min, int max) +rb_arity_error_new(int argc, int min, int max, VALUE mname, VALUE file, VALUE lineno) { VALUE err_mess = rb_sprintf("wrong number of arguments (given %d, expected %d", argc, min); if (min == max) { @@ -497,13 +497,19 @@ rb_arity_error_new(int argc, int min, int max) rb_str_catf(err_mess, "..%d", max); } rb_str_cat_cstr(err_mess, ")"); + if (mname) { + rb_str_catf(err_mess, "\nfor %"PRIsVALUE, mname); + if (file) { + rb_str_catf(err_mess, " at %"PRIsVALUE":%"PRIsVALUE, file, lineno); + } + } return rb_exc_new3(rb_eArgError, err_mess); } void rb_error_arity(int argc, int min, int max) { - rb_exc_raise(rb_arity_error_new(argc, min, max)); + rb_exc_raise(rb_arity_error_new(argc, min, max, Qfalse, Qfalse, INT2FIX(0))); } /* lvar */ ``` ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:122842] [Ruby Feature#21518] Statistical helpers to `Enumerable`
by Amitleshed (Amit Leshed) 22 Aug '25

22 Aug '25

Issue #21518 has been reported by Amitleshed (Amit Leshed). ---------------------------------------- Feature #21518: Statistical helpers to `Enumerable` https://bugs.ruby-lang.org/issues/21518 * Author: Amitleshed (Amit Leshed) * Status: Open ---------------------------------------- **Summary** I'd like to add two statistical helpers to `Enumerable`: - `Enumerable#average` (arithmetic mean) - `Enumerable#median` Both are small, well-defined operations that many Rubyists re-implement in apps and gems. Providing them in core avoids repeated, ad-hoc code and aligns with `Enumerable#sum`, which Ruby already ships. **Motivation** - These are among the most common “roll-your-own” helpers for arrays/ranges of numbers. - They are conceptually simple, universally useful beyond web/Rails. - Similar to `sum`, they’re primitives for quick data analysis, ETL scripts, CLI tooling, etc. - Including them encourages consistent semantics (what to do with empty sets, mixed numerics, etc.). ## Proposed API & Semantics ```ruby Enumerable#average -> Float or nil Enumerable#median -> Numeric or nil ``` ```ruby [1, 2, 3, 4].average # => 2.5 (1..4).average # => 2.5 [].average # => nil [1, 3, 2].median # => 2 [1, 2, 3, 10].median # => 2.5 (1..6).median # => 3.5 [].median # => nil ``` Ruby implementation ```ruby module Enumerable def average count = 0 total = 0.0 each do |x| raise TypeError, "non-numeric value for average" unless x.is_a?(Numeric) total += x count += 1 end count.zero? ? nil : total / count end def median arr = to_a return nil if arr.empty? arr.each { |x| raise TypeError, "non-numeric value for median" unless x.is_a?(Numeric) } arr.sort! mid = arr.length / 2 arr.length.odd? ? arr[mid] : (arr[mid - 1] + arr[mid]) / 2.0 end end ``` **Upon approval I'm more than willing to implement spec and code in C.** -- https://bugs.ruby-lang.org/

8 11

[ruby-core:122969] [Ruby Feature#21545] `#try_dig`: a dig that returns early if it cannot dig deeper
by cb341 (Daniel Bengl) 22 Aug '25

22 Aug '25

Issue #21545 has been reported by cb341 (Daniel Bengl). ---------------------------------------- Feature #21545: `#try_dig`: a dig that returns early if it cannot dig deeper https://bugs.ruby-lang.org/issues/21545 * Author: cb341 (Daniel Bengl) * Status: Open ---------------------------------------- Ruby offers `dig` for traversing nested hashes and arrays. It is strict and will raise if an intermediary object does not support `dig`. In many cases we only want to attempt the lookup and return `nil` if it cannot be followed, without caring about the exact reason. **Example:** ```rb { a: "foo" }.dig(:a, :b) # TypeError: String does not have #dig method { a: "foo" }.try_dig(:a, :b) # => nil ``` This is especially useful when dealing with data from APIs or other inconsistent sources: ```rb api_response = { status: "ok" } api_response.try_dig(:status, :code) # => nil api_response = { status: { code: 200 } } api_response.try_dig(:status, :code) # => 200 ``` The name `try_dig` makes it clear that it behaves like `dig` but will never raise for structural mismatches. It complements `dig` and the proposed `dig!` ([#12282](https://bugs.ruby-lang.org/issues/12282), [#15563](https://bugs.ruby-lang.org/issues/15563)) by covering the tolerant lookup case. A possible sketch: ```rb class Object def try_dig(*path) current = self path.each do |key| return nil unless current.respond_to?(:dig) begin current = current.dig(key) rescue StandardError return nil end end current end end ``` **Advantages** - Simplifies tolerant lookups without repetitive rescue logic - Clear intent when the value is optional - Useful for working with inconsistent or partially known data structures - Complements `dig` and potential `dig!` by covering the tolerant case **Disatvantages** - May hide structural issues that should be noticed during development -- https://bugs.ruby-lang.org/

5 4

[ruby-core:123042] [Ruby Feature#21550] Ractor.sharable_proc/sharable_lambda to make sharable Proc object
by ko1 (Koichi Sasada) 22 Aug '25

22 Aug '25

Issue #21550 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #21550: Ractor.sharable_proc/sharable_lambda to make sharable Proc object https://bugs.ruby-lang.org/issues/21550 * Author: ko1 (Koichi Sasada) * Status: Open * Assignee: ko1 (Koichi Sasada) * Target version: 3.5 ---------------------------------------- Let's introduce a way to make a sharable Proc. * `Ractor.shareable_proc(self: nil, &block)` makes proc. * `Ractor.shareable_lambda(self: nil, &block)` makes lambda. See also: https://bugs.ruby-lang.org/issues/21039 ## Background ### Motivation Being able to create a shareable Proc is important for Ractors. For example, we often want to send a task to another Ractor: ```ruby worker = Ractor.new do while task = Ractor.receive task.call(...) end end task = (sharable_proc) worker << task task = (sharable_proc) worker << task task = (sharable_proc) worker << task ``` There are various ways to represent a task, but using a Proc is straightforward. However, to make a Proc shareable today, self must also be shareable, which leads to patterns like: ```ruby nil.instance_eval{ Proc.new{ ... } } ``` This is noisy and cryptic. We propose dedicated methods to create shareable Proc objects directly. ## Specification * `Ractor.shareable_proc(self: nil, &block)` makes a proc. * `Ractor.shareable_lambda(self: nil, &block)` makes a lambda. Both methods create the Proc/lambda with the given self and make the resulting object shareable. Captured outer variables follow the current `Ractor.make_shareable` semantics: * If a captured outer local variable refers to a shareable object, a shareable Proc may read it. * If any captured outer variable refers to a non‑shareable object, creating the shareable Proc raises an error. ```ruby a = 42 b = "str" Ractor.sharalbe_proc{ p a #=> 42 } Ractor.sharalbe_proc{ # error when making a sharealbe proc p b #=> 42 } ``` * The captured outer local variables are copied by value when the shareable Proc is created. Subsequent modifications of those variables in the creator scope do not affect the Proc. ``` a = 42 shpr = Ractor.sharable_proc{ p a } a = 0 shpr.call #=> 42 ``` ``` * Assigning to outer local variables from within the shareable Proc is not allowed (error at creation). ```ruby a = 42 Ractor.shareable_proc{ # error when making a sharealbe proc a = 43 } ``` More about outer-variable handling are discussed below. In other words, from the perspective of a shareable Proc, captured outer locals are read‑only constants. This proposal does not change the semantics of Ractor.make_shareable() itself. ## Discussion about outer local variables [Feature #21039] discusses how captured variables should be handled. I propose two options. ### 1. No problem to change the @Eregon noted that the current behavior of `Ractor.make_shareable(proc_obj)` can surprise users. While that is understandable, Ruby already has similar *surprises*. For instance: ```ruby RSpec.describe 'foo' do p self #=> RSpec::ExampleGroups::Foo end ``` Here, `self` is implicitly replaced, likely via `instance_exec`. This can be surprising if one does not know self can change, yet it is accepted in Ruby. We view the current situation as a similar kind of surprise. ### 2. Enforce a strict rule for non‑lexical usage The difficulty is that it is hard to know which block will become shareable unless it is lexically usage. ```ruby # (1) On this code, it is clear that the block will be shareable block: a = 42 Ractor.sharable_proc{ p a } # (2) On this code, it is not clear that the block becomes sharable or not get path do p a end # (3) On this code, it has no problem because get '/hello' do "world" end ``` The idea is to allow accessing captured outer variables only for lexically explicit uses of `Ractor.shareable_proc` as in (1), and to raise an error for non‑lexical cases as in (2). So the example (3) is allowed if the block becomes sharable or not. The strict rule is same as `Ractor.new` block rule. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122917] [Ruby Feature#21532] Define most of Pathname in Ruby code
by Eregon (Benoit Daloze) 22 Aug '25

22 Aug '25

Issue #21532 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21532: Define most of Pathname in Ruby code https://bugs.ruby-lang.org/issues/21532 * Author: Eregon (Benoit Daloze) * Status: Open * Assignee: Eregon (Benoit Daloze) ---------------------------------------- There was discussion in #17473 and before to define most of Pathname in Ruby code and not in the C extension. I have made a PR to achieve that: https://github.com/ruby/pathname/pull/57 I would like to merge it soon to avoid conflicts. Once upon a time, Pathname was pure-Ruby: https://github.com/ruby/ruby/blob/95bc02237635d3fe42532bfe53038257575cee75/… This PR goes back to that, and reuses that original Ruby code, but keeps the C extension implementation of `<=>` and `sub` as those two are significantly faster. The other Pathname methods are actually faster in Ruby than in C, because all these methods just do `rb_funcall()` and `rb_ivar_get()` and those in C code have no inline cache, but the corresponding method calls and `@path` have inline caches in Ruby code. https://railsatscale.com/2023-08-29-ruby-outperforms-c/ is an explanation of that. Therefore having Pathname defined in Ruby seems a clear win for many reasons: * Much clearer implementation, so easier to read what the code does * Easier to maintain * Safer (no risk of accessing out of bounds memory or e.g. passing the wrong number of arguments to `rb_funcall`) * Actually faster, because of these inline caches, see numbers at the end of https://github.com/ruby/pathname/pull/57#issue-3234862768 * Better for JITs as they can optimize this, notably `...` vs the C extension being a blackbox * Works on JRuby (which does not support C extensions) * Faster on TruffleRuby (where a C extension for this is inefficient as it causes needless Ruby->C->Ruby transitions) -- https://bugs.ruby-lang.org/

3 4

[ruby-core:122925] [Ruby Feature#21533] Introduce `Time#am?` and `Time#pm?`
by matheusrich (Matheus Richard) 22 Aug '25

22 Aug '25

Issue #21533 has been reported by matheusrich (Matheus Richard). ---------------------------------------- Feature #21533: Introduce `Time#am?` and `Time#pm?` https://bugs.ruby-lang.org/issues/21533 * Author: matheusrich (Matheus Richard) * Status: Open ---------------------------------------- This proposal adds two predicate methods to `Time`: ```ruby Time.utc(2000, 1, 1, 11, 59, 59).am? # => true Time.utc(2000, 1, 1, 12, 0, 0).pm? # => true ``` * `am?` returns true when the hour is less than 12. * `pm?` returns true when the hour is 12 or greater. These methods provide a clear and expressive way to branch logic based on time of day. For example: ```ruby def reminder_deferral_options options = [] options << ["Later today", "later_today"] if Time.now.am? options << ["Tomorrow morning", "tomorrow_morning"] options << ["Pick a date/time…", "custom"] options end ``` This is a common pattern in applications involving reminders and scheduling. The method names are intuitive, and the semantics are well understood. The implementation is in [this Pull Request](https://github.com/ruby/ruby/pull/14133). -- https://bugs.ruby-lang.org/

5 9

[ruby-core:123045] [Ruby Feature#14718] Use jemalloc by default?
by mame (Yusuke Endoh) 21 Aug '25

21 Aug '25

Issue #14718 has been updated by mame (Yusuke Endoh). Status changed from Open to Rejected jemalloc development has been discontinued. https://jasone.github.io/2025/06/12/jemalloc-postmortem/ ---------------------------------------- Feature #14718: Use jemalloc by default? https://bugs.ruby-lang.org/issues/14718#change-114362 * Author: mperham (Mike Perham) * Status: Rejected ---------------------------------------- I know Sam opened #9113 4 years ago to suggest this but I'm revisiting the topic to see if there's any movement here for Ruby 2.6 or 2.7. I supply a major piece of Ruby infrastructure (Sidekiq) and I keep hearing over and over how Ruby is terrible with memory, a huge memory hog with their Rails apps. My users switch to jemalloc and a miracle occurs: their memory usage drops massively. Some data points: https://twitter.com/brandonhilkert/status/987400365627801601 https://twitter.com/d_jones/status/989866391787335680 https://github.com/mperham/sidekiq/issues/3824#issuecomment-383072469 Redis moved to jemalloc many years ago and it solved all of their memory issues too. Their conclusion: the glibc allocator "sucks really really hard". http://oldblog.antirez.com/post/everything-about-redis-24.html This is a real pain point for the entire Rails community and would improve Ruby's reputation immensely if we can solve this problem. ---Files-------------------------------- glibc_arena_2.png (7.23 KB) jemalloc.png (21.1 KB) glibc-arena-2.log (60.3 KB) glibc.log (62.3 KB) jemalloc-3-5.log (58.5 KB) glibc.png (9.03 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120873] [Ruby master Bug#21111] RbConfig::CONFIG['CXX'] quietly set to "false" when Ruby cannot build C++ programs
by stanhu (Stan Hu) 21 Aug '25

21 Aug '25

Issue #21111 has been reported by stanhu (Stan Hu). ---------------------------------------- Bug #21111: RbConfig::CONFIG['CXX'] quietly set to "false" when Ruby cannot build C++ programs https://bugs.ruby-lang.org/issues/21111 * Author: stanhu (Stan Hu) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- As reported in https://gitlab.com/gitlab-org/gitlab-development-kit/-/issues/2222 and https://trac.macports.org/ticket/70750, we've had numerous macOS users experience problems with compiling Ruby C++ extensions after upgrading to XCode 16. Users have had to fix their XCode setups and reinstall Ruby when this happens. It turns out that when Ruby can't build a CXX program, it essentially sets CXX to the `false` string. From https://github.com/ruby/ruby/blob/7317f96727725ca37ddb06011918deb841de371c/…: ``` AS_IF([test -n "${rb_there_is_in_fact_no_gplusplus_but_autoconf_is_cheating_us}"], [ AC_MSG_NOTICE([Test skipped due to lack of a C++ compiler.]) ], [test -n "${CXX}"], [ RUBY_WERROR_FLAG([ AC_MSG_CHECKING([whether CXXFLAGS is valid]) AC_LANG_PUSH(C++) AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[@%:@include <cstdio>]], [[]])], [AC_MSG_RESULT(yes)],[ AC_MSG_RESULT(no) # The message mentions CXXFLAGS, but CPPFLAGS might also affects. AC_MSG_WARN([something wrong with CXXFLAGS="$CXXFLAGS"]) CXX=false ``` This causes C++ extensions, such as `unf_ext`, to fail while attempting to compile native extensions. There are no error messages because `false` is executed, so users only see: ``` Installing unf_ext 0.0.8.2 with native extensions Gem::Ext::BuildError: ERROR: Failed to build gem native extension. current directory: /Users/myuser/.rvm/gems/ruby-3.3.7/gems/unf_ext-0.0.8.2/ext/unf_ext /Users/kerrizor/.rvm/rubies/ruby-3.3.7/bin/ruby extconf.rb checking for -lstdc++... yes creating Makefile current directory: /Users/myuser/.rvm/gems/ruby-3.3.7/gems/unf_ext-0.0.8.2/ext/unf_ext make DESTDIR\= sitearchdir\=./.gem.20250203-69237-u2oi17 sitelibdir\=./.gem.20250203-69237-u2oi17 clean current directory: /Users/myuser/.rvm/gems/ruby-3.3.7/gems/unf_ext-0.0.8.2/ext/unf_ext make DESTDIR\= sitearchdir\=./.gem.20250203-69237-u2oi17 sitelibdir\=./.gem.20250203-69237-u2oi17 compiling unf.cc make: *** [unf.o] Error 1 ``` `unf_ext` only checks whether `RbConfig::CONFIG['CXX']` is defined, not that it is `false`: https://github.com/knu/ruby-unf_ext/blob/c72a36d0a5ea9fe3950611b0f289fc68a2…. Questions: 1. Should CXX just be set to `nil`? Or should all C++ extensions be expected to check for `false`? The latter seems surprising to me. 2. Should there be a way to fail the Ruby build if a valid C++ compiler is not found? -- https://bugs.ruby-lang.org/

7 9

[ruby-core:122953] [Ruby Bug#21540] prism allows `foo && return bar` when parse.y doesn't
by Earlopain (Earlopain _) 21 Aug '25

21 Aug '25

Issue #21540 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21540: prism allows `foo && return bar` when parse.y doesn't https://bugs.ruby-lang.org/issues/21540 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 3.5.0dev (2025-08-08T02:57:23Z master 3ad26d0501) [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Code such as `foo && return bar` has been disallowed in ruby since at least Ruby 2.0. Prism allows it though: ``` $ ruby -cve "a && return foo" ruby 3.5.0dev (2025-08-08T02:57:23Z master 3ad26d0501) +PRISM [x86_64-linux] Syntax OK $ ruby --parser=parse.y -cve "a && return foo" ruby 3.5.0dev (2025-08-08T02:57:23Z master 3ad26d0501) [x86_64-linux] -e:1: syntax error, unexpected local variable or method, expecting end-of-input a && return foo ruby: compile error (SyntaxError) ``` The code seems to behave like I'd expect it to and I wouldn't mind it being accepted but it is inconsistent. -- https://bugs.ruby-lang.org/

4 6