February 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:124705] [Ruby Bug#21867] enabling Ruby::Box changes puts/warn to no longer use $stdout/$stderr
by zenspider (Ryan Davis) 06 Feb '26

06 Feb '26

Issue #21867 has been reported by zenspider (Ryan Davis). ---------------------------------------- Bug #21867: enabling Ruby::Box changes puts/warn to no longer use $stdout/$stderr https://bugs.ruby-lang.org/issues/21867 * Author: zenspider (Ryan Davis) * Status: Open * ruby -v: 4.0.1+ * Backport: 4.0: UNKNOWN ---------------------------------------- On 4.0.1 or latest build as of 2026-02-06, given: ```ruby warn "run with RUBY_BOX=1 to repro the error" unless ENV["RUBY_BOX"] require "stringio" def capture_io captured_stdout, captured_stderr = StringIO.new, StringIO.new orig_stdout, orig_stderr = $stdout, $stderr $stdout, $stderr = captured_stdout, captured_stderr yield return captured_stdout.string, captured_stderr.string ensure $stdout = orig_stdout $stderr = orig_stderr end out, err = capture_io do puts "standard out!" # these go to STDOUT/STDERR, not $stdout/$stderr warn "standard err?" $stdout.print "standard out!" # these go to the stringio as expected $stderr.print "standard err?" end exp_out = "standard out!\nstandard out!" exp_err = "standard err?\nstandard err?" p OUT: out, EXP: exp_out unless out == exp_out p ERR: out, EXP: exp_err unless err == exp_err abort "bad" unless out == exp_out && err == exp_err p :good! ``` I get: ``` 10026 $ ./build/miniruby --disable=gems,did_you_mean -I./lib ./tool/runruby.rb --extout=build/.ext --archdir=build -- test_box.rb run with RUBY_BOX=1 to repro the error :good! ``` vs w/ box enabled: ``` 10027 $ RUBY_BOX=1 ./build/miniruby --disable=gems,did_you_mean -I./lib ./tool/runruby.rb --extout=build/.ext --archdir=build -- test_box.rb ... box warnings ... standard out! standard err? {OUT: "standard out!", EXP: "standard out!\nstandard out!"} {ERR: "standard out!", EXP: "standard err?\nstandard err?"} bad ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116028] [Ruby master Feature#20152] mkmf / extconf: Add a proper way to not compile the extension
by byroot (Jean Boussier) 06 Feb '26

06 Feb '26

Issue #20152 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20152: mkmf / extconf: Add a proper way to not compile the extension https://bugs.ruby-lang.org/issues/20152 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context There are various gems that ship with a native extension as a way to speedup part of the gem, but also ship with a pure Ruby version of these methods as a fallback. So they only want to compile the extension if the platform supports it, and if not, just fallback to the slightly slower Ruby version. Right now users rely on one of two hacks to do this. Either they create an empty Makefile, but then still depend on `make` being available, or publish platform specific packages without any extension in them. Examples: - [`bootsnap` skip compilation if not on MRI or TruffleRuby](https://github.com/Shopify/bootsnap/blob/070151f1305f23102365d… - [`erb` has an extension for MRI but then need to publish a `java` version of the gem that doesn't actually contain Java code, just to skip compilation on JRuby](https://github.com/ruby/erb/issues/52) - [`hiredis-client` skips the compilation for Windows and non-MRI rubies](https://github.com/redis-rb/redis-client/blob/1ab081c1d0e47df5d55e0… ### Feature It would be very useful to have some proper first class API to skip compiling the extension. Something like: ```ruby require "mkmf" if RUBY_ENGINE != "ruby" || RUBY_PLATFORM.match?(/mswin/) skip_compilation else # ... end ``` cc @k0kubun @headius -- https://bugs.ruby-lang.org/

10 21

[ruby-core:124694] [Ruby Feature#12906] do/end blocks work with ensure/rescue/else
by zverok (Victor Shepelev) 06 Feb '26

06 Feb '26

Issue #12906 has been updated by zverok (Victor Shepelev). > I tried finding out why this is called `ensure`/`rescue`/`else` when it only handles `ensure` and `rescue`? ```ruby begin File.read(filename) rescue ArgumentError puts "wrong arguments" rescue Errno::ENOENT puts "file does not exist" else puts "read successfully" end ``` `else` is part of `rescue` clause that invoked if no exception was raised; it is useful to do some post-body actions that doesn't affect the main flow (though affects the exception-handling return value). It is _documented_ [here](https://docs.ruby-lang.org/en/master/language/exceptions_md.html#else…. > I thought this might be something like the empty iterator pattern that is used in some frontend frameworks. I don't think this is possible to implement in Ruby without very serious effort and a significant toll to the mental model of the language. In your code example, `else` clause is part of the block's body; a block is mostly a "black box" for a method that receives it, and only can be interacted with via `block.call(args)`; invoking _some_ of the block statements conditionally is a questionable road. Though not unimaginable. ---------------------------------------- Feature #12906: do/end blocks work with ensure/rescue/else https://bugs.ruby-lang.org/issues/12906#change-116288 * Author: josh.cheek (Josh Cheek) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) * Target version: 2.5 ---------------------------------------- When you want to rescue in a block, you must do this: ~~~ruby lambda do begin raise 'err' rescue $! # => #<RuntimeError: err> end end.call ~~~ I've wished on numerous occasions that I could omit the begin/end and not need the extra wrapper: ~~~ruby lambda do raise 'err' rescue $! # => #<RuntimeError: err> end.call ~~~ This would be consistent with how classes and methods work: ~~~ruby class C raise 'err' rescue $! # => #<RuntimeError: err> end send def m raise 'err' rescue $! # => #<RuntimeError: err> end ~~~ It's not really clear to me how to submit this since it may require some discussion, but this is the diff: ~~~diff diff --git a/parse.y b/parse.y index 54ccc52..223e5d3 100644 --- a/parse.y +++ b/parse.y @@ -3757,7 +3757,7 @@ brace_body : {$<vars>$ = dyna_push();} do_body : {$<vars>$ = dyna_push();} {$<val>$ = cmdarg_stack >> 1; CMDARG_SET(0);} - opt_block_param compstmt + opt_block_param bodystmt { $$ = new_do_body($3, $4); dyna_pop($<vars>1); ~~~ I added tests for ensure to rubyspec, but there wasn't an obvious place to talk about rescue/else in this context (the spec for rescue only uses it in a begin/end block) It's probably fine as the spec for ensure does hit rescue, too, and they ultimately delegate to the same pieces. Not totally clear, though. I can do more with that if you need. ~~~diff diff --git a/language/ensure_spec.rb b/language/ensure_spec.rb index 13575fc..b14b0b5 100644 --- a/language/ensure_spec.rb +++ b/language/ensure_spec.rb @@ -124,3 +124,74 @@ describe "An ensure block inside a method" do @obj.explicit_return_in_method_with_ensure.should == :ensure end end + +describe "An ensure block inside a do block" do + before :each do + ScratchPad.record [] + end + + it "is executed when an exception is raised in it's corresponding do block" do + begin + lambda do + ScratchPad << :begin + raise "An exception occured!" + ensure + ScratchPad << :ensure + end.should raise_error(RuntimeError) + + ScratchPad.recorded.should == [:begin, :ensure] + end + end + + it "is executed when an exception is raised and rescued in it's corresponding do block" do + begin + lambda do + ScratchPad << :begin + raise "An exception occured!" + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + + ScratchPad.recorded.should == [:begin, :rescue, :ensure] + end + end + + it "is executed even when a symbol is thrown in it's corresponding do block" do + begin + catch(:symbol) do + lambda do + ScratchPad << :begin + throw(:symbol) + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + end + + ScratchPad.recorded.should == [:begin, :ensure] + end + end + + it "is executed when nothing is raised or thrown in it's corresponding do block" do + lambda do + ScratchPad << :begin + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + + ScratchPad.recorded.should == [:begin, :ensure] + end + + it "has no return value" do + lambda do + :begin + ensure + :ensure + end.call.should == :begin + end +end ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124687] [Ruby Bug#21864] Inconsistencies in type coercion error messages for integers
by herwin (Herwin W) 05 Feb '26

05 Feb '26

Issue #21864 has been reported by herwin (Herwin W). ---------------------------------------- Bug #21864: Inconsistencies in type coercion error messages for integers https://bugs.ruby-lang.org/issues/21864 * Author: herwin (Herwin W) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux], but consisten since at least Ruby 3.2, haven't checked older releases * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Some context in https://github.com/ruby/spec/pull/1345, all code snippets are run using Ruby 4.0.1 on a 64bit Linux (Debian) system, unless stated otherwise. Ruby has some generic type coercion error message. For example: ```ruby File.truncate(var, 1) ``` Depending on the type of `var`, it can generate error messages like: ``` no implicit conversion of Integer into String (TypeError) no implicit conversion of false into String (TypeError) ``` In general `true`, `false` and `nil` print the string representation of the object, anything else prints the class of the object. One could argue that this is inconsistent, but it's probably better than printing `NilClass` in the error (something I've recently seen happen in Natalie and TruffleRuby, I would guess JRuby occasionally has this issue as well, but I haven't looked for it. The exact error messages are often missing in the Ruby specs). The conversion to integer is weird. ```ruby File.truncate("/dev/zero", var) ``` Anything other than `nil` gets pretty much the same output as before: ``` no implicit conversion of Symbol into Integer (TypeError) no implicit conversion of false into Integer (TypeError ``` But this is where nil has a special path: ``` no implicit conversion from nil to integer (TypeError) ``` Now it's usng "from .. to" instead of "of .. into", and `integer` is written in lower case. But, this message is not consistent either, based on the size of `off_t`, where the coercion uses either `rb_num2long` or `rb_num2ll`, which have different checks for `nil`: ```c // Taken from commit 86dba8cfaeabb3b86df921da24b3243b9ce4ab2a long rb_num2long(VALUE val) { again: if (NIL_P(val)) { rb_raise(rb_eTypeError, "no implicit conversion from nil to integer"); } LONG_LONG rb_num2ll(VALUE val) { if (NIL_P(val)) { rb_raise(rb_eTypeError, "no implicit conversion from nil"); } ``` That last one has some internal checks for other types, with more inconsistent error messages: ```c rb_raise(rb_eTypeError, "no implicit conversion from string"); rb_raise(rb_eTypeError, "no implicit conversion from boolean"); ``` That last one looks like the only error message to mention the term `boolean`. IMHO the first message type is the clearest, so I would propose to write every coercion failure in this way: ```ruby type = value.nil? || value == true || value == "false" ? value.inspect : value.class klass = "String" # Or Integer, or ... "no implicit conversion of #{type} into #{klass}" ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:124689] [Ruby Feature#12906] do/end blocks work with ensure/rescue/else
by phoet 05 Feb '26

05 Feb '26

Issue #12906 has been updated by phoet (Peter Schröder). I tried finding out why this is called `ensure/rescue/else` when it only handles `ensure` and `rescue`? Stumbled open this in the Ruby version history https://rubyreferences.github.io/rubychanges/2.5.html#rescueelseensure-are-… I thought this might be something like the empty iterator pattern that is used in some frontend frameworks. ``` def print_elements elements.each do |e| puts e else puts "No Elements" end end ``` ---------------------------------------- Feature #12906: do/end blocks work with ensure/rescue/else https://bugs.ruby-lang.org/issues/12906#change-116282 * Author: josh.cheek (Josh Cheek) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) * Target version: 2.5 ---------------------------------------- When you want to rescue in a block, you must do this: ~~~ruby lambda do begin raise 'err' rescue $! # => #<RuntimeError: err> end end.call ~~~ I've wished on numerous occasions that I could omit the begin/end and not need the extra wrapper: ~~~ruby lambda do raise 'err' rescue $! # => #<RuntimeError: err> end.call ~~~ This would be consistent with how classes and methods work: ~~~ruby class C raise 'err' rescue $! # => #<RuntimeError: err> end send def m raise 'err' rescue $! # => #<RuntimeError: err> end ~~~ It's not really clear to me how to submit this since it may require some discussion, but this is the diff: ~~~diff diff --git a/parse.y b/parse.y index 54ccc52..223e5d3 100644 --- a/parse.y +++ b/parse.y @@ -3757,7 +3757,7 @@ brace_body : {$<vars>$ = dyna_push();} do_body : {$<vars>$ = dyna_push();} {$<val>$ = cmdarg_stack >> 1; CMDARG_SET(0);} - opt_block_param compstmt + opt_block_param bodystmt { $$ = new_do_body($3, $4); dyna_pop($<vars>1); ~~~ I added tests for ensure to rubyspec, but there wasn't an obvious place to talk about rescue/else in this context (the spec for rescue only uses it in a begin/end block) It's probably fine as the spec for ensure does hit rescue, too, and they ultimately delegate to the same pieces. Not totally clear, though. I can do more with that if you need. ~~~diff diff --git a/language/ensure_spec.rb b/language/ensure_spec.rb index 13575fc..b14b0b5 100644 --- a/language/ensure_spec.rb +++ b/language/ensure_spec.rb @@ -124,3 +124,74 @@ describe "An ensure block inside a method" do @obj.explicit_return_in_method_with_ensure.should == :ensure end end + +describe "An ensure block inside a do block" do + before :each do + ScratchPad.record [] + end + + it "is executed when an exception is raised in it's corresponding do block" do + begin + lambda do + ScratchPad << :begin + raise "An exception occured!" + ensure + ScratchPad << :ensure + end.should raise_error(RuntimeError) + + ScratchPad.recorded.should == [:begin, :ensure] + end + end + + it "is executed when an exception is raised and rescued in it's corresponding do block" do + begin + lambda do + ScratchPad << :begin + raise "An exception occured!" + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + + ScratchPad.recorded.should == [:begin, :rescue, :ensure] + end + end + + it "is executed even when a symbol is thrown in it's corresponding do block" do + begin + catch(:symbol) do + lambda do + ScratchPad << :begin + throw(:symbol) + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + end + + ScratchPad.recorded.should == [:begin, :ensure] + end + end + + it "is executed when nothing is raised or thrown in it's corresponding do block" do + lambda do + ScratchPad << :begin + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + + ScratchPad.recorded.should == [:begin, :ensure] + end + + it "has no return value" do + lambda do + :begin + ensure + :ensure + end.call.should == :begin + end +end ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124664] [Ruby Bug#21859] Inconsistent behaviors in Regexp lookbehind/lookahead with capture groups
by trinistr (Alexander Bulancov) 05 Feb '26

05 Feb '26

Issue #21859 has been reported by trinistr (Alexander Bulancov). ---------------------------------------- Bug #21859: Inconsistent behaviors in Regexp lookbehind/lookahead with capture groups https://bugs.ruby-lang.org/issues/21859 * Author: trinistr (Alexander Bulancov) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- First issue: `Regexp.linear_time?` is `false` for a positive lookahead with a capture, but `true` for a positive lookbehind: ```ruby irb(main):002> Regexp.linear_time?(/(?=(a))/) => false irb(main):003> Regexp.linear_time?(/(?<=(a))/) => true ``` This should be `false` in both cases. Second issue: Capture group is allowed in a negative lookahead, but causes a `SyntaxError` in a negative lookbehind: ```ruby irb(main):001> /(?!(a))b/ => /(?!(a))b/ irb(main):002> /(?<!(a))b/ /home/alex/.local/share/mise/installs/ruby/4.0.1/lib/ruby/gems/4.0.0/gems/irb-1.16.0/exe/irb:9:in '<top (required)>': (irb):2: invalid pattern in look-behind: /(?<!(a))b/ (SyntaxError) ``` I believe such a capture group can never capture anything, so it probably should be an error in both cases. -- https://bugs.ruby-lang.org/

3 7

[ruby-core:124680] [Ruby Bug#21862] dtrace is passed unmodified CPPFLAGS, but not all compiler flags are supported by dtrace
by wiz (Thomas Klausner) 05 Feb '26

05 Feb '26

Issue #21862 has been reported by wiz (Thomas Klausner). ---------------------------------------- Bug #21862: dtrace is passed unmodified CPPFLAGS, but not all compiler flags are supported by dtrace https://bugs.ruby-lang.org/issues/21862 * Author: wiz (Thomas Klausner) * Status: Open * ruby -v: 4.0.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I use "CPPFLAGS=-g" to enable symbols in my builds. This works for most software, except for ruby. The problem is that, in template/Makefile.in, CPPFLAGS are passed unmodified to dtrace: ``` .d.h: @$(ECHO) translating probes $< $(Q) $(DTRACE) -o $@.tmp -h -C $(INCFLAGS) $(CPPFLAGS) -s $< ``` which on NetBSD leads to a dtrace usage warning, because -g is not supported: ``` BASERUBY = ./tool/missing-baseruby.bat CC = gcc LD = ld LDSHARED = gcc -shared CFLAGS = -O2 -g -fstack-clash-protection -pthread -I/usr/pkg/include -I/usr/include -fPIC -pipe XCFLAGS = -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -I. -I.ext/include/x86_64-netbsd -I.ext/include -I./include -I. -I./prism -I./enc/unicode/17.0.0 -Dmodular_gc_dir= CPPFLAGS = -g -I/usr/pkg/include -I/usr/include DLDFLAGS = -Wl,-zrelro -Wl,-znow -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib -pthread -Wl,--compress-debug-sections=zlib -Wl,-soname,libruby40.so.40 SOLIBS = -lexecinfo -lz -lrt -lrt -lcrypt -lm -lpthread LANG = C LC_ALL = C LC_CTYPE = C MFLAGS = RUSTC = rustc YJIT_RUSTC_ARGS = --crate-name=yjit --crate-type=staticlib --cfg feature="stats_allocator" --edition=2021 -g -C lto=thin -C opt-level=3 -C overflow-checks=on '--out-dir=/tmp/lang/ruby40/work/ruby-4.0.1/tar get/release/' './yjit/src/lib.rs' ZJIT_RUSTC_ARGS = --crate-name=zjit --crate-type=staticlib --cfg feature="stats_allocator" --edition=2024 -g -C lto=thin -C opt-level=3 -C overflow-checks=on '--out-dir=/tmp/lang/ruby40/work/ruby-4.0.1/tar get/release/' './zjit/src/lib.rs' gcc (nb2 20260118) 14.3.0 Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. compiling ./main.c compiling dmydln.c compiling miniinit.c translating probes probes.d dtrace: unknown option -- g Usage: dtrace [-32|-64] [-aACeFGhHlqSvVwZ] [-b bufsz] [-c cmd] [-D name[=def]] [-I path] [-L path] [-o output] [-p pid] [-s script] [-U name] [-x opt[=val]] [-X a|c|s|t] [-P provider [[ predicate ] action ]] [-m [ provider: ] module [[ predicate ] action ]] [-f [[ provider: ] module: ] func [[ predicate ] action ]] [-n [[[ provider: ] module: ] func: ] name [[ predicate ] action ]] [-i probe-id [[ predicate ] action ]] [ args ... ] ... ``` which breaks the build. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:124677] [Ruby Feature#21861] C API: expose `ruby_xfree_sized`, `ruby_xrealloc_sized`, etc
by byroot (Jean Boussier) 05 Feb '26

05 Feb '26

Issue #21861 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21861: C API: expose `ruby_xfree_sized`, `ruby_xrealloc_sized`, etc https://bugs.ruby-lang.org/issues/21861 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context For the longest time now, Ruby had internal API such as `ruby_sized_xfree`, `ruby_sized_xrealloc` and `ruby_sized_xrealloc2`. These are identical to their non-sized counterpart, expect they accept the original size of the buffer being free or reallocated. This information is then fed to the garbage collector to improve heuristics as to when GC should run (`malloc_increase_bytes` and `oldmalloc_increase_bytes`). When the old buffer size isn't provided, Ruby tries to obtain it via `malloc_usable_size`, which isn't available on all platform, but also isn't quite correct as it's generally over reporting. It also happen to be quite slow on some allocators, such as `mallocng`, the allocator used by `muslc` hence by alpine linux. ### C23 `free_sized` The C23 standard added the `free_sized(void *ptr, size_t oldsize)` API, and it's now available in `glibc 2.43`, other popular allocators like `jemalloc` and `tcmalloc` also have it since a few years. Original spec: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2699.htm Interestingly the standard doesn't include a `realloc_sized` API, I'm unsure why. For most allocators, providing the size to `free_sized` allow to skip some step and provide a speedup. I've read some 30% claims, but I haven't benchmarked myself. One thing to note is that according to the standard, passing the wrong size is undefined behavior: > If ptr is the result obtained from a call to `malloc(size)`, `realloc(old_ptr, size)`, or `calloc(nmemb, memb_size)`, where `nmemb * memb_size` is equal to `size`, this function behaves equivalently to `free(ptr)`. Otherwise, the result is undefined. Recently I refactored most internal calls to `xfree` inside Ruby itself to use `ruby_sized_xfree` instead, and would like to have it use `free_sized` when available. Also when `RUBY_DEBUG` is defined, `xmalloc` does register the original allocated size, and enforce that the size provided to `ruby_sized_xfree` does match. This allowed to uncover several small bugs, notably in `string.c` where we'd sometime end up with an incorrect `capacity` attribute after an encoding change. ### Benefits Aside from the performance gains on some allocators, and the gains from having more accurate GC statistics, I believe these sized interfaces help ensure correctness of the code. Except for a few exceptions, most code dealing with a buffer must know its size to avoid going out of bound, so providing it to `ruby_xfree_sized` allows to assert the size was correctly tracked in debug builds. I also believe ASAN or UBSAN are likely to also enforce this soon (if they don't already), so it could help catch more bugs early. ### Proposal I would like to expose these sized APIs to C extensions, so that they can benefit from it as well: - `void ruby_xfree_sized(void *ptr, size_t oldsize)` - `void *ruby_xrealloc_sized(void *ptr, size_t newsize, size_t oldsize)` - `void *ruby_xrealloc2_sized(void *ptr, size_t n, size_t size, size_t old_n)` I also think I would be useful to expose the corresponding macros: - `RB_REALLOC_SIZED_N` - `RB_SIZED_FREE` (shorthand to free a simple pointer: `ruby_xfree_sized(ptr, sizeof(*ptr))`). - `RB_SIZED_FREE_N` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124359] [Ruby Misc#21804] Getting setup-ruby Earlier
by koic (Koichi ITO) 03 Feb '26

03 Feb '26

Issue #21804 has been reported by koic (Koichi ITO). ---------------------------------------- Misc #21804: Getting setup-ruby Earlier https://bugs.ruby-lang.org/issues/21804 * Author: koic (Koichi ITO) * Status: Open ---------------------------------------- ruby/setup-ruby is commonly used for development in OSS projects and real-world Rails applications. https://github.com/ruby/setup-ruby This is not specific to Ruby 4.0.0. There is often a delay between a Ruby release and the availability of the corresponding version in setup-ruby. setup-ruby is maintained by the ruby organization and may take a few days to become available after a Ruby release. In contrast, ruby-build is maintained by the rbenv organization and tends to become available shortly after a Ruby release. This makes it easier to start using new Ruby versions immediately. If setup-ruby maintained by the ruby organization were released shortly after a Ruby release, users could start using new Ruby versions sooner. It is difficult to determine whether this issue should be registered on bugs.ruby-lang.org. Since setup-ruby is maintained by the ruby organization, this issue is being opened to raise awareness of the situation. If this is not appropriate, please feel free to close it. Thank you for your continued maintenance and for releasing Ruby. -- https://bugs.ruby-lang.org/

9 17

[ruby-core:123681] [Ruby Bug#21669] Thoroughly implement void value expression check
by mame (Yusuke Endoh) 03 Feb '26

03 Feb '26

Issue #21669 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #21669: Thoroughly implement void value expression check https://bugs.ruby-lang.org/issues/21669 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: prism * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- A void-value-expression check is a syntax check that raises a `SyntaxError` if an expression that cannot grammatically return a value (a "void value expression," such as a `return` expression) appears in a context where a value is expected (e.g., the right-hand side of an assignment, the argument of a method call, etc.). A typical example rejected by this check is `x = return`. However, it has become clear that this check is incomplete. This ticket summarizes the results of a discussion with @matz at the hackathon before RubyWorld Conference today. ## 1\. Expressions containing branches @matz said that an expression containing branches should be considered a void value expression only if it can be grammatically determined that all possible branches do not return a value. Based on this, both parse.y and prism currently reject the following code with a "void value expression" `SyntaxError`, but it should be accepted: ```ruby x = begin raise return rescue "OK" else return end # Expected: Code parses and executes successfully. # Actual: Rejected with "unexpected void value expression" SyntaxError. ``` Reason: The `rescue` clause can return a value ("OK"), so the entire `begin` expression is not void. Conversely, the following code is currently accepted by both parse.y and prism, but it should be rejected: ```ruby x = begin foo rescue return else return end # Expected: Rejected with SyntaxError. # Actual: Code parses and executes. ``` Reason: This expression always does `return`, so it is void whether `foo` raises an exception or not. Furthermore, `case` expressions must also be rejected similarly when all branches are void: ```ruby x = case when 1; return when 2; return else return end # Expected: Rejected with SyntaxError. # Actual: Code parses and executes. ``` Note that `if` expressions appear to be implemented correctly as intended: ```ruby x = if rand < 0.5 return else return end # Expected: Rejected with SyntaxError. # Actual: Rejected. (OK!) ``` ## 2\. Statement lists containing a void value expression @matz also said that if a statements node contains a void value expression, the entire statement list should be treated as a void value expression, even if the void expression is not the last one. Therefore, the following code is currently accepted but should be rejected: ```ruby x = begin return "NG" end # Expected: Rejected with SyntaxError. # Actual: Code parses and executes. ``` The same applies to branches within other expressions: ```ruby x = if rand < 0.5 return "NG" else return end # Expected: Rejected with SyntaxError. # Actual: Code parses and executes. ``` Note that if a return statement is inside a branch, that statement cannot be considered a void value expression, so the entire expression also cannot be a void value expression. ```ruby x = begin return if true "NG" end # Expected: Code parses and executes. # Actual: Code parses and executes as expected. (OK!) ``` --- This is considered a bug, but if it causes practical compatibility issues, it may be necessary to plan a migration path or revisit the specifications. (Both prism and parse.y need to be fixed, but I'll assign it to the prism team for now.) -- https://bugs.ruby-lang.org/

6 15