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

[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: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