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

[ruby-core:124460] [Ruby Feature#6012] Proc#source_location also return the column
by mame (Yusuke Endoh) 08 Jan '26

08 Jan '26

Issue #6012 has been updated by mame (Yusuke Endoh). Eregon (Benoit Daloze) wrote in #note-49: > In any case I don't think it's our place to judge whether each usage is "valid" or "correct" or not, it's definitely useful functionality since it's used so much. "I don't know exactly what users are using the `method_source` gem for, but since it's used so much, we should provide equivalent functionality as a built-in feature" This argument can hardly persuade anyone... However, let’s assume we proceed with that logic. In that case, `source_location` would have to follow the behavior of the `method_source` gem exactly, without questioning its validity (including heredocs and the glitch-like behavior you pointed out). Since we do not know the user's ultimate purpose, there is a possibility that those glitch-like behaviors happen to be exactly what satisfies the user. Is that really what you want? > Nobody expects the `StatementsNode` instead of the `CallNode` for `Prism.node_for(Proc)`. To give an extreme example, suppose we implement a TracePoint like `:ast_node_enter` that fires every time the interpreter evaluates each Prism node (as like a tree-walking interpreter). In that scenario, `Prism.node_for(TracePoint)` would need to distinguish between a `StatementsNode` and a `CallNode`. Also, Ruby's grammar will certainly continue to change, and I have no doubt that the instances of overlapping Nodes, beyond just `StatementsNode` and `CallNode`, can increase accordingly. > I do agree with you that for final use case of getting a Prism AST, #21795 would be more direct and safer (e.g. can check hash of the file). > And there it's totally fine to use `node_id` internally on CRuby, as it remains an implementation detail not exposed to the user. I agree with this. While #21795 seems like a heavy task with many issues to resolve, I think it is a sound approach in the sense that it is better to hide the implementation details of how to map Ruby objects to AST nodes. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-116011 * Author: rogerdpack (Roger Pack) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122552] [Ruby Feature#21442] Make tsort to bundled gems
by hsbt (Hiroshi SHIBATA) 08 Jan '26

08 Jan '26

Issue #21442 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21442: Make tsort to bundled gems https://bugs.ruby-lang.org/issues/21442 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- In last year, I gave up to make `tsort` to bundled gems because `set` depends `tsort`. https://github.com/ruby/set/blob/29a253d2259e8d6d9b313dec8418ec5ed0caab08/l… Fortunately, `set` is now core class. So, there is no library depends on `tsort` in ruby repository. I propose to make `tsort` to bundled gems at the next release(not Ruby 3.5/4.0, for 4.0(?)/4.1) -- https://bugs.ruby-lang.org/

1 3

[ruby-core:123453] [Ruby Bug#21634] Combining read(1) with eof? causes dropout of results unexpectedly on Windows.
by YO4 (Yoshinao Muramatsu) 08 Jan '26

08 Jan '26

Issue #21634 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21634: Combining read(1) with eof? causes dropout of results unexpectedly on Windows. https://bugs.ruby-lang.org/issues/21634 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-03T08:59:54Z master 5b2ec0eb1b) +PRISM [x64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- On Windows, when reading a file containing EOF(\x1A), using read(1) with IO#eof? causes unexpected dropout of results. ```ruby irb(main):001> IO.binwrite("txt", "abcd\x1A") => 5 irb(main):002> open("txt", "r") { p _1.read(1) until _1.eof? }; # works fine "a" "b" "c" "d" "\x1A" irb(main):003> open("txt", "rt") { p _1.read(1) until _1.eof? }; # has failure "b" "d" irb(main):004> ``` The problem disappeared when I commented out one of the following lines (though this will break other things). * previous_mode = set_binary_mode_with_seek_cur(fptr); in io_read() * flush_before_seek(fptr, false); in set_binary_mode_with_seek_cur(() * io_unread(fptr, discard_rbuf); in flush_before_seek() Within io_unread(), rbuf.len should have changed as 5, 4, 3,... but instead changed as 4, 2,(end). Since inconsistencies already exist at this point, the problem appears to originate elsewhere. I found this in ruby master but the same issue was found at least in ruby-1.9.3-p551. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:123829] [Ruby Bug#21691] On Windows some of binary read functions of IO are not functional
by YO4 (Yoshinao Muramatsu) 08 Jan '26

08 Jan '26

Issue #21691 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21691: On Windows some of binary read functions of IO are not functional https://bugs.ruby-lang.org/issues/21691 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When using the binary read method of IO on a file containing “\r\n”, it should read “\r”, but some methods do not function correctly on Windows. ```ruby File.binwrite("crlf.txt", "\r\n") methods = { readn: proc { |f| f.read(1) }, getbyte: proc { |f| f.getbyte.chr }, readbyte: proc { |f| f.readbyte.chr }, readpartial: proc { |f| f.readpartial(1) }, read_nonblock: proc { |f| f.read_nonblock(1) }, sysread: proc { |f| f.sysread(1) }, pread: proc { |f| f.pread(1, 0) }, } def test(mode, name, method) open("crlf.txt", "r") do |f| p [mode, name, method.call(f)] end end methods.each { |k, v| test("r", k, v) } methods.each { |k, v| test("rt", k, v) } ``` results: ```ruby ["r", :readn, "\r"] ["r", :getbyte, "\n"] # => shold be "\r" ["r", :readbyte, "\n"] # => shold be "\r" ["r", :readpartial, "\n"] # => shold be "\r" ["r", :read_nonblock, "\n"] # => shold be "\r" ["r", :sysread, "\n"] # => shold be "\r" ["r", :pread, "\r"] ["rt", :readn, "\r"] ["rt", :getbyte, "\n"] # => shold be "\r" ["rt", :readbyte, "\n"] # => shold be "\r" ["rt", :readpartial, "\n"] # => shold be "\r" ["rt", :read_nonblock, "\n"] # => shold be "\r" ["rt", :sysread, "\n"] # => shold be "\r" ["rt", :pread, "\r"] ``` On Ubuntu in WSL, all returns are “\r”. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:124025] [Ruby Bug#21763] Windows: output IO pipe ignores crlf newline conversion specified by set_encoding
by YO4 (Yoshinao Muramatsu) 08 Jan '26

08 Jan '26

Issue #21763 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21763: Windows: output IO pipe ignores crlf newline conversion specified by set_encoding https://bugs.ruby-lang.org/issues/21763 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- On Windows, output pipes have no crlf conversion applied by default except for stdout/stderr, also it ignore set_encoding(crlf_newline: true). ``` > ruby -e "IO.pipe { |r,w| w.set_encoding('ascii-8bit', crlf_newline: true); w.puts ?a; w.close; p r.binmode.read }" "a\n" # => "a\r\n" is expected ``` On other platforms, this is effective. ``` $ ruby -e "IO.pipe { |r,w| w.set_encoding('ascii-8bit', crlf_newline: true); w.puts ?a; w.close; p r.binmode.read }" "a\r\n" ``` This occurs only when using the C runtime _write() for newline conversion. It works correctly when performing CRLF conversion using encoding conversion. ``` > ruby -e "IO.pipe { |r,w| w.set_encoding('us-ascii', crlf_newline: true); w.puts ?a; w.close; p r.binmode.read }" "a\r\n" ``` This also affects an IO duped from stdout. ``` > ruby -e "STDOUT.puts ?a; STDOUT.dup.puts ?b" | ruby -e "p STDIN.binmode.read" "a\r\nb\n" # => "b\n" seems to wrong ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124029] [Ruby Bug#21765] stop using the C runtime _read() on Windows
by YO4 (Yoshinao Muramatsu) 08 Jan '26

08 Jan '26

Issue #21765 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21765: stop using the C runtime _read() on Windows https://bugs.ruby-lang.org/issues/21765 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When creating an IO instance in Windows, the default data mode is text mode. In reality, the IO encoding conversion mechanism is not used when encoding conversion is not performed. Instead, the CRLF conversion provided by the C runtime's `_read()` is used. This is explicitly for speed. https://bugs.ruby-lang.org/issues/6401#note-4 As a trade-off, `SET_BINARY_MODE(fptr)` and `SET_BINARY_MODE_WITH_SEEK_CUR(fptr)` are used in various places within io.c, altering the state of the file descriptor. This made the flow of operations difficult to understand and changes hard to implement, especially for developers on other platforms. Additionally, the issues I recently reported were discovered while verifying the impact of modifying the CRLF conversion to utilize the encoding conversion mechanism. #21691 On Windows some of binary read functions of IO are not functional #21687 IO＃pos goes wrong after EOF character(ctrl-z) met #21634 Combining read(1) with eof? causes dropout of results unexpectedly on Windows. These issues arise because data read into the rbuf does not match the stream due to newline conversion, or because the buffer end and file position do not align when CTRLZ is detected. As a fix for Bug #21687, I created PR #15216. However, this relies on the internal behavior of the C runtime's `_read()` function, and it seems there is no way to avoid this dependency. **I propose removing the use of C runtime _read().** Reason for Proposal - The mismatch between rbuf and stream contents complicates io_unread() and makes maintenance difficult. - Changing the O_BINARY/O_TEXT state of the file descriptor in various places hinders understanding of the behavior and makes modifications difficult. Two methods to remove C runtime _read() while maintaining current behavior 1. Interpret CRLF and CTRLZ when reading rbuf within io.c. 1. Interpret CRLF and CTRLZ within the encoding conversion framework. My initial idea was to implement the second, using encoding conversion. However, this internally changes the read operation from rbuf to cbuf, resulting in a change to the behavior of ungetc. The proposal in Bug #21682 attempted to generalize this change to minimize its impact. https://bugs.ruby-lang.org/issues/21682 **This issue proposes the first method, crlf conversion during rbuf read.** Problems caused by inconsistencies between the rbuf and stream contents are avoided, and io_unread() becomes the same as on other platforms. Compared to implementing it as an encoding conversion, the advantage is that there is no change in behavior. On the other hand, since each read method in io.c requires individual handling, using encoding conversion results in more localized changes. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:121699] [Ruby Feature#21277] Windows ARM support
by hsbt (Hiroshi SHIBATA) 08 Jan '26

08 Jan '26

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

1 1

[ruby-core:124448] [Ruby Bug#21829] test
by h0w1e (howie qin) 08 Jan '26

08 Jan '26

Issue #21829 has been reported by h0w1e (howie qin). ---------------------------------------- Bug #21829: test https://bugs.ruby-lang.org/issues/21829 * Author: h0w1e (howie qin) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ---Files-------------------------------- xss_verysmall.xlsx (747 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124447] [Ruby Misc#17376] Reduce number of GitHub Actions
by hsbt (Hiroshi SHIBATA) 08 Jan '26

08 Jan '26

Issue #17376 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed The current job number is 94 each commit and GitHub improved their UI of GitHub Actions. I'm closing this. ---------------------------------------- Misc #17376: Reduce number of GitHub Actions https://bugs.ruby-lang.org/issues/17376#change-115995 * Author: naruse (Yui NARUSE) * Status: Closed * Assignee: shyouhei (Shyouhei Urabe) ---------------------------------------- At this time we have 127 checks for GitHub commits, but unfortunately GitHub UI only shows 100 checks. It sometimes makes we don't see a failed check. Could you reduce number of GitHub actions at least less than 100? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124446] [Ruby Feature#17210] More readable and useful `Set#inspect`
by hsbt (Hiroshi SHIBATA) 08 Jan '26

08 Jan '26

Issue #17210 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed ``` ❯ ruby -ve "puts Set[1,2,3]" ruby 4.1.0dev (2026-01-06T23:05:30Z master b2ed4cdced) +YJIT +MN +PRISM [arm64-darwin25] Set[1, 2, 3] ``` Ruby 4.0 introduced this feature request. ---------------------------------------- Feature #17210: More readable and useful `Set#inspect` https://bugs.ruby-lang.org/issues/17210#change-115994 * Author: marcandre (Marc-Andre Lafortune) * Status: Closed * Assignee: knu (Akinori MUSHA) ---------------------------------------- I would like to change `Set#inspect`/`to_s`: ```ruby # before puts Set[1,2,3] # => "#<Set: {1, 2, 3}>" # after puts Set[1,2,3] # => "Set[1, 2, 3]" ``` This output is shorter, readable, and has the property that it corresponds to Ruby code -- https://bugs.ruby-lang.org/

1 0