December 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:119632] [Ruby master Feature#20818] Allow passing a block to Hash#store (to update current value)
by furunkel (Julian Aron Prenner) 12 Dec '24

12 Dec '24

Issue #20818 has been reported by furunkel (Julian Aron Prenner). ---------------------------------------- Feature #20818: Allow passing a block to Hash#store (to update current value) https://bugs.ruby-lang.org/issues/20818 * Author: furunkel (Julian Aron Prenner) * Status: Open ---------------------------------------- I would like to propose a block form for `Hash#store`. In addition to passing a value, it should also be allowed to pass a block. If passed a block instead of a value, the block is called with the current value or, if unset, the hash's default value; the block's return value will be the value that is stored. This is similar to e.g., `computeIfPresent`/`computeIfAbsent` in Java (I think). I can think of several situations where this would be useful, in particular for caches and counters. For instance: ```ruby counts = {} elements.each do |element| counts.store(element){ (_1 || 0) + element.weight} end ``` or even more elegant with a default value: ```ruby counts = {} counts.default = 0 elements.each do |element| counts.store(element){ _1 + element.weight} end ``` Moreover, using the block form we should be able to do operations such as `h[k] ||= x`, `h[k] -= x`, `h[k] += x`, or more generally `h[k] = f(h[k])`, with a single "hashing round-trip". If I'm not mistaken, currently these involve two separate calls to `#[]` and `#[]=` (with two calls to `#hash`?). Finally, this makes `#store` a proper dual of `#fetch` which, similarly, can be passed a block. I have an experimental implementation of this (GitHub PR) at: https://github.com/ruby/ruby/pull/11956 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120114] [Ruby master Bug#20932] Socket fast_fallback segfaults when fds are > FD_SETSIZE
by jhawthorn (John Hawthorn) 12 Dec '24

12 Dec '24

Issue #20932 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #20932: Socket fast_fallback segfaults when fds are > FD_SETSIZE https://bugs.ruby-lang.org/issues/20932 * Author: jhawthorn (John Hawthorn) * Status: Open * Assignee: shioimm (Misaki Shioi) * Target version: 3.4 * ruby -v: ruby 3.4.0dev (2024-12-04T21:46:02Z master bf225feb26) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When `Socket.tcp_fast_fallback = true` and a socket ends up with an FD over FD_SETSIZE (typically 1024), it results in a buffer overflow and crashes when running FD_SET before select. It may be necessary to update ulimits to be above 1024 before reproducing (`ulimit -n 2048`) ``` require "socket" open_fds = [] loop do file = open(__FILE__) open_fds << file break if file.fileno >= 1010 end #Socket.tcp_fast_fallback=false TCPServer.open("localhost", 0) do |server| port = server.addr[1] sockets = [] 50.times do |i| socket = TCPSocket.open("localhost", port) p socket sockets << socket end end ``` ``` $ ulimit -n 2048 $ ruby test.rb #<TCPSocket:fd 1015, AF_INET6, ::1, 40622> #<TCPSocket:fd 1014, AF_INET6, ::1, 40628> #<TCPSocket:fd 1016, AF_INET6, ::1, 40630> #<TCPSocket:fd 1017, AF_INET6, ::1, 40632> #<TCPSocket:fd 1018, AF_INET6, ::1, 40644> #<TCPSocket:fd 1020, AF_INET6, ::1, 40658> #<TCPSocket:fd 1021, AF_INET6, ::1, 40668> #<TCPSocket:fd 1019, AF_INET6, ::1, 40674> #<TCPSocket:fd 1022, AF_INET6, ::1, 40678> #<TCPSocket:fd 1023, AF_INET6, ::1, 40694> ================================================================= ==3180778==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ae35aadc580 at pc 0x7ae35b1b7449 bp 0x7fffc9af1af0 sp 0x7fffc9af1ae8 READ of size 8 at 0x7ae35aadc580 thread T0 #0 0x7ae35b1b7448 in init_fast_fallback_inetsock_internal /home/jhawthorn/src/ruby/ext/socket/ipsocket.c:912:17 #1 0x60462ff14879 in rb_ensure /home/jhawthorn/src/ruby/eval.c:1053:18 #2 0x7ae35b1b41b9 in rsock_init_inetsock /home/jhawthorn/src/ruby/ext/socket/ipsocket.c:1315:20 #3 0x7ae35b1bae9a in tcp_init /home/jhawthorn/src/ruby/ext/socket/tcpsocket.c:91:12 #4 0x604630178944 in vm_call0_cfunc_with_frame /home/jhawthorn/src/ruby/./vm_eval.c:164:15 #5 0x604630176ade in vm_call0_body /home/jhawthorn/src/ruby/./vm_eval.c:229:15 #6 0x604630146e46 in vm_call0_cc /home/jhawthorn/src/ruby/./vm_eval.c:101:12 #7 0x604630178ffd in rb_call0 /home/jhawthorn/src/ruby/./vm_eval.c:554:12 #8 0x604630147e3a in rb_call /home/jhawthorn/src/ruby/./vm_eval.c:873:12 #9 0x60462ffe15cd in rb_class_new_instance_kw /home/jhawthorn/src/ruby/object.c:2187:5 #10 0x60462ff6c39c in rb_io_s_open /home/jhawthorn/src/ruby/io.c:8126:16 #11 0x604630166e9c in vm_call_cfunc_with_frame_ /home/jhawthorn/src/ruby/./vm_insnhelper.c:3801:11 #12 0x604630134dad in vm_sendish /home/jhawthorn/src/ruby/./vm_insnhelper.c #13 0x60463013c68b in vm_exec_core /home/jhawthorn/src/ruby/insns.def:898:11 #14 0x604630135327 in rb_vm_exec /home/jhawthorn/src/ruby/vm.c:2585:22 #15 0x60463017ba7c in invoke_iseq_block_from_c /home/jhawthorn/src/ruby/vm.c:1615:12 #16 0x60463017ba7c in invoke_block_from_c_bh /home/jhawthorn/src/ruby/vm.c:1629:20 #17 0x60463014b477 in vm_yield_with_cref /home/jhawthorn/src/ruby/vm.c:1666:12 #18 0x604630148937 in rb_yield /home/jhawthorn/src/ruby/./vm_eval.c #19 0x60462ff14879 in rb_ensure /home/jhawthorn/src/ruby/eval.c:1053:18 #20 0x604630166e9c in vm_call_cfunc_with_frame_ /home/jhawthorn/src/ruby/./vm_insnhelper.c:3801:11 #21 0x604630159de6 in vm_call_method_each_type /home/jhawthorn/src/ruby/./vm_insnhelper.c:4779:16 #22 0x604630159afe in vm_call_method /home/jhawthorn/src/ruby/./vm_insnhelper.c #23 0x604630134dad in vm_sendish /home/jhawthorn/src/ruby/./vm_insnhelper.c #24 0x60463013ba52 in vm_exec_core /home/jhawthorn/src/ruby/insns.def:851:11 #25 0x60463015113b in vm_exec_loop /home/jhawthorn/src/ruby/vm.c:2612:22 #26 0x60463013533a in rb_vm_exec /home/jhawthorn/src/ruby/vm.c #27 0x60462ff12f0c in rb_ec_exec_node /home/jhawthorn/src/ruby/eval.c:281:9 #28 0x60462ff12d12 in ruby_run_node /home/jhawthorn/src/ruby/eval.c:319:30 #29 0x60462ff0ed73 in rb_main /home/jhawthorn/src/ruby/./main.c:43:12 #30 0x60462ff0ec47 in main /home/jhawthorn/src/ruby/./main.c:68:12 #31 0x7ae35c5e7e07 in __libc_start_call_main /usr/src/debug/glibc/glibc/csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #32 0x7ae35c5e7ecb in __libc_start_main /usr/src/debug/glibc/glibc/csu/../csu/libc-start.c:360:3 #33 0x60462fe2f334 in _start (/home/jhawthorn/.rubies/ruby-asan/bin/ruby+0x174334) Address 0x7ae35aadc580 is located in stack of thread T0 at offset 384 in frame #0 0x7ae35b1b44df in init_fast_fallback_inetsock_internal /home/jhawthorn/src/ruby/ext/socket/ipsocket.c:537 This frame has 14 object(s): [32, 36) 'status' (line 544) [48, 50) 'resolved_type' (line 555) [64, 72) 'pipefd' (line 558) [96, 224) 'readfds' (line 559) [256, 384) 'writefds' (line 559) <== Memory access at offset 384 overflows this variable [416, 456) 'wait_arg' (line 561) [496, 512) 'delay' (line 563) [528, 568) 'resolution_store' (line 567) [608, 624) 'resolution_delay_storage' (line 604) [640, 656) 'connection_attempt_delay_strage' (line 606) [672, 688) 'user_specified_resolv_timeout_storage' (line 608) [704, 720) 'user_specified_connect_timeout_storage' (line 610) [736, 740) 'err' (line 953) [752, 756) 'len' (line 954) HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow /home/jhawthorn/src/ruby/ext/socket/ipsocket.c:912:17 in init_fast_fallback_inetsock_internal Shadow bytes around the buggy address: 0x7ae35aadc300: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 0x7ae35aadc380: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 0x7ae35aadc400: f1 f1 f1 f1 04 f2 02 f2 00 f2 f2 f2 00 00 00 00 0x7ae35aadc480: 00 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 0x7ae35aadc500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x7ae35aadc580:[f2]f2 f2 f2 00 00 00 00 00 f2 f2 f2 f2 f2 00 00 0x7ae35aadc600: f2 f2 00 00 00 00 00 f2 f2 f2 f2 f2 00 00 f2 f2 0x7ae35aadc680: 00 00 f2 f2 00 00 f2 f2 00 00 f2 f2 f8 f2 f8 f3 0x7ae35aadc700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ae35aadc780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ae35aadc800: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==3180778==ABORTING ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120217] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by nobu (Nobuyoshi Nakada) 12 Dec '24

12 Dec '24

Issue #6648 has been updated by nobu (Nobuyoshi Nakada). Eregon (Benoit Daloze) wrote in #note-44: > Are you thinking if the directory is removed? In that case there is no way to rerun the command faithfully, so an error like Errno::ENOENT is fine. Removed or renamed. It can rerun fine by removing `-C` options and staying in the current directory. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-110981 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120050] [Ruby master Feature#20922] Should not we omit parentheses in assert calls?
by mame (Yusuke Endoh) 12 Dec '24

12 Dec '24

Issue #20922 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #20922: Should not we omit parentheses in assert calls? https://bugs.ruby-lang.org/issues/20922 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- I often see the style of omitting parentheses in assert calls, but it leads to annoying warnings in the following case: ``` assert_equal -1, val #=> warning: ambiguous first argument; put parentheses or a space even after `-` operator assert_match /foo/, str #=> warning: ambiguous `/`; wrap regexp in parentheses or add a space after `/` operator ``` To deal with this warning, it is necessary to add parentheses only to *some* assert calls. ``` assert_equal 1, one assert_equal 0, zero assert_equal(-1, minus_one) ``` Obviously, this is not very cool. I feel that by these warnings, Ruby says "we should not omit parentheses in assert calls". Is this what matz intended? If it is the intent, I would like to add parentheses on all assert calls in tests of Ruby and default gems. If it is not the intent, why don't we remove these warnings? Note that, as far as I recall, I encountered this problem only with `assert_equal` and `assert_match`. I don't write parentheses in `p`, `puts`, `attr_reader`, `include`, etc., but all of them rarely accept `-1` and `//` literally as the first argument in real code. As a milder approach, I came up with an idea to stop the warning only when the method name starts with "assert". It is very ad-hoc, though. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:119622] [Ruby master Bug#20817] Ruby 3.4.0dev emits `warning: possibly useless use of + in void context` while Ruby 3.3.5 does not
by yahonda (Yasuo Honda) 12 Dec '24

12 Dec '24

Issue #20817 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #20817: Ruby 3.4.0dev emits `warning: possibly useless use of + in void context` while Ruby 3.3.5 does not https://bugs.ruby-lang.org/issues/20817 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 3.4.0dev (2024-10-25T11:52:32Z master 9c8c140d73) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Ruby 3.4.0dev emits `warning: possibly useless use of + in void context` while Ruby 3.3.5 does not This issue is based on Rails Action Pack test case against Ruby 3.4.0dev. Here is the minimum script to reproduce it. ### Steps to reproduce - Create a sample foo.rb file ``` class C class_eval "def throw_syntax_error; eval %( 'abc' + pluralize 'def' ); end", "lib/file.rb", 42 end c = C.new c.throw_syntax_error ``` - Run this foo.rb using Ruby 3.4.0dev ### Expected behavior It should report SyntaxError, but it shoud not emit any warnings as Ruby 3.3.5 does not. ``` $ ruby -v ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux] $ ruby -w foo.rb lib/file.rb:42:in `eval': (eval at lib/file.rb:42):2: syntax error, unexpected string literal, expecting `do' or '{' or '(' (SyntaxError) 'abc' + pluralize 'def' ^ from lib/file.rb:42:in `throw_syntax_error' from foo.rb:7:in `<main>' ``` ### Actual behavior It reports It should SyntaxError and it emits the `warning: possibly useless use of + in void context` ``` $ ruby -v ruby 3.4.0dev (2024-10-25T11:52:32Z master 9c8c140d73) +PRISM [x86_64-linux] $ ruby -w foo.rb (eval at lib/file.rb:42):2: warning: possibly useless use of + in void context lib/file.rb:42:in 'Kernel#eval': (eval at lib/file.rb:42):2: syntax error found (SyntaxError) 1 | > 2 | 'abc' + pluralize 'def' | ^ unexpected string literal, expecting end-of-input 3 | from lib/file.rb:42:in 'C#throw_syntax_error' from foo.rb:7:in '<main>' $ ``` -- https://bugs.ruby-lang.org/

5 7

[ruby-core:120104] [Ruby master Bug#20930] Different semantics for nested `it` and `_1`
by Eregon (Benoit Daloze) 12 Dec '24

12 Dec '24

Issue #20930 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #20930: Different semantics for nested `it` and `_1` https://bugs.ruby-lang.org/issues/20930 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.4.0dev (2024-12-04T19:29:24Z master 3c91a1e5fd) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ``` $ ruby -ve '[1].each { p it; [5].each { p it } }' ruby 3.4.0dev (2024-12-04T19:29:24Z master 3c91a1e5fd) +PRISM [x86_64-linux] 1 5 $ ruby -ve '[1].each { p _1; [5].each { p _1 } }' ruby 3.4.0dev (2024-12-04T19:29:24Z master 3c91a1e5fd) +PRISM [x86_64-linux] 1 1 ``` Notice the inconsistency, `it` uses the innermost block, `_1` uses the outermost block. I think `_1` semantics are slightly better, at least `_1` behaves like a normal local variable declared in the outer block then. Note that on 3.3.5 it was forbidden to nest `_1` which I think might be good for clarity/avoiding ambiguity: ``` $ ruby -ve '[1].each { p _1; [5].each { p _1 } }' ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux] -e:1: numbered parameter is already used in -e:1: outer block here [1].each { p _1; [5].each { p _1 } } ruby: compile error (SyntaxError) ``` --- As an aside, mixing `_1` and `it` is allowed, I think this is [good](https://bsky.app/profile/eregon.bsky.social/post/3lcg4fjcf7225), they are different things so there is not much confusion there: ``` $ ruby -ve '[1].each { p _1; [5].each { p it } }' ruby 3.4.0dev (2024-12-04T19:29:24Z master 3c91a1e5fd) +PRISM [x86_64-linux] 1 5 $ ruby -ve '[1].each { p it; [5].each { p _1 } }' ruby 3.4.0dev (2024-12-04T19:29:24Z master 3c91a1e5fd) +PRISM [x86_64-linux] 1 5 ``` -- https://bugs.ruby-lang.org/

3 6

[ruby-core:120149] [Ruby master Bug#20940] Colored syntax error from prism
by ko1 (Koichi Sasada) 12 Dec '24

12 Dec '24

Issue #20940 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Bug #20940: Colored syntax error from prism https://bugs.ruby-lang.org/issues/20940 * Author: ko1 (Koichi Sasada) * Status: Open * Assignee: matz (Yukihiro Matsumoto) * Target version: 3.4 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Prism shows syntax error with coloring. But we have long avoided coloring Ruby for reasons such as color weakness. Can we release next Ruby 3.4.0 with colored syntax errors? ![colored_syntax_error1](clipboard-202412101454-v5ydy.png) ![colored_syntax_error2](clipboard-202412101456-u1hrp.png) NOTE: * irb supports `NO_COLOR` environment variable ([NO_COLOR: disabling ANSI color output by default](https://no-color.org/)) ---Files-------------------------------- clipboard-202412101454-v5ydy.png (20.6 KB) clipboard-202412101456-u1hrp.png (10.7 KB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120027] [Ruby master Misc#20913] Proposal: Adding Jeremy Evans and Burdette Lamar to www.ruby-lang.org's English Editorial Team
by st0012 (Stan Lo) 12 Dec '24

12 Dec '24

Issue #20913 has been reported by st0012 (Stan Lo). ---------------------------------------- Misc #20913: Proposal: Adding Jeremy Evans and Burdette Lamar to www.ruby-lang.org's English Editorial Team https://bugs.ruby-lang.org/issues/20913 * Author: st0012 (Stan Lo) * Status: Open ---------------------------------------- Hi everyone, I'd like to propose that we invite @jeremyevans0 and @burdettelamar to join the editorial team for [ruby-lang.org](https://ruby-lang.org)'s English content. Specifically, this means giving them permission to merge English content pull requests into the [ruby/www.ruby-lang.org GitHub repo](https://github.com/ruby/www.ruby-lang.org). Both Jeremy and Burdette are long-time Ruby committers who have made significant contributions to Ruby and the community. During RubyConf in Chicago this month, a few members from [Ruby Central](https://rubycentral.org/) and I discussed with them the idea of improving the website, and they both expressed enthusiasm for taking on this new role. Recently, we've been seeing increased contributions to the content of [ruby-lang.org/en](https://ruby-lang.org/en), and there are plenty of opportunities for further improvements as well. Adding Jeremy and Burdette to the team would help us enhance our reviewing capacity and keep the momentum going. What do you think? -- https://bugs.ruby-lang.org/

5 5

[ruby-core:119663] [Ruby master Bug#20858] multiple parallel assignments are inconsistent
by daveola (David Stellar) 12 Dec '24

12 Dec '24

Issue #20858 has been reported by daveola (David Stellar). ---------------------------------------- Bug #20858: multiple parallel assignments are inconsistent https://bugs.ruby-lang.org/issues/20858 * Author: daveola (David Stellar) * Status: Open * ruby -v: ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I may have terminology wrong, so apologies. For this bug I'm going to use "multiple assignment" to refer to using multiple assignment operators in a line, such as: ``` ruby a = b = c = 1 ``` And then parallel assignment to refer to doing multiple assignments at the same time using tuples, such as: ``` ruby a,b = 1, 2 ``` Unfortunately combining these is inconsistent. First of all, just doing this: ``` ruby a,b = c,d = 3,4 ``` Gives us: **"undefined local variable or method `c' for main (NameError)"** So if we work around that by defining all our variables, we then get unexpected results: ``` ruby a = b = c = d = 'foobar' a,b = c,d = 3,4 puts "Got: a=#{a} b=#{b} and c=#{c} d=#{d}" # Got: a=foobar b=3 and c=foobar d=3 c,d = 3,4 a,b = c,d puts "Got: a=#{a} b=#{b} and c=#{c} d=#{d}" # Got: a=3 b=4 and c=3 d=4 ``` I can imagine that if multiple parallel assignment is not supported that a,b will not get set properly, but it does not follow that c would be undefined by the expression. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120179] [Ruby master Bug#20945] Behaviour mismatch between parse.y and prism with character literals AST nodes
by viralpraxis (Iaroslav Kurbatov) 11 Dec '24

11 Dec '24

Issue #20945 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Bug #20945: Behaviour mismatch between parse.y and prism with character literals AST nodes https://bugs.ruby-lang.org/issues/20945 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open * ruby -v: ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- AST string node (character literals) values returned by parse.y are, for some reason, frozen, whereas Prism does not freeze them: ``` ruby require 'prism' require 'parser/current' puts Prism::VERSION puts Parser::VERSION p Prism.parse('?a').value.statements.child_nodes.first.content.then { [_1.class, _1.frozen?] } p Parser::CurrentRuby.parse('?a').children[0].then { [_1.class, _1.frozen? ]} p Prism.parse('?\n').value.statements.child_nodes.first.content.then { [_1.class, _1.frozen?] } p Parser::CurrentRuby.parse('?\n').children[0].then { [_1.class, _1.frozen? ]} ``` output: ``` 1.2.0 3.3.6.0 [String, false] [String, false] [String, false] [String, true] ``` I’m not sure whether this is a bug in Parser, Prism, or something else. -- https://bugs.ruby-lang.org/

2 2