- ruby-core - ml.ruby-lang.org

[ruby-core:115752] [Ruby master Feature#18083] Capture error in ensure block.
by Dan0042 (Daniel DeLorme) 15 Dec '23

15 Dec '23

Issue #18083 has been updated by Dan0042 (Daniel DeLorme). ko1 (Koichi Sasada) wrote in #note-20: > my proposal is introducing dynamic scope, not syntactical scope like: I think this is a good idea, definitely an improvement over the current situation. `$!` is already always correct inside a `rescue` clause, and that would make it always correct inside the `ensure` clause. But I want to confirm if this would be the expected behavior: ```ruby #1 p $! #=> A begin # no raise ensure p $! #=> nil (unlike A currently) end p $! #=> A (restored after previous begin-ensure block?) #2 p $! #=> A begin raise "B" rescue p $! #=> B #not re-raised ensure p $! #=> B (unlike A currently) end p $! #=> A (restored after previous begin-ensure block?) ``` ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105683 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115748] [Ruby master Feature#18083] Capture error in ensure block.
by kddnewton (Kevin Newton) 14 Dec '23

14 Dec '23

Issue #18083 has been updated by kddnewton (Kevin Newton). If you're already using global variables, we could add another global variable that gets set in `ensure` blocks that determines if an error was raised. That way you could safely check `$!`. That wouldn't require a syntax change. ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105680 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115747] [Ruby master Feature#18083] Capture error in ensure block.
by ioquatix (Samuel Williams) 14 Dec '23

14 Dec '23

Issue #18083 has been updated by ioquatix (Samuel Williams). Here is a good example of why `$!` is dangerous: https://github.com/ruby/net-ftp/pull/24 I believe the merged fix is also wrong, since flow control can exit without closing the connection. ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105679 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115739] Ruby 3.2.2 Solaris-Sparc Compilation Error in iseq.c
by Jay Mav 14 Dec '23

14 Dec '23

Hello, Building Ruby 3.2.2 on Solaris-Sparc 32-bit with Developer Studio 12.6. Issues: 1) compilation of iseq.c fails due to variable definition in macro OPTION: #define SET_COMPILE_OPTION(o, h, mem) \ { VALUE flag = rb_hash_aref((h), ID2SYM(rb_intern(#mem))); \ if (flag == Qtrue) { (o)->mem = 1; } \ else if (flag == Qfalse) { (o)->mem = 0; } \ } SET_COMPILE_OPTION(option, opt, inline_const_cache); SET_COMPILE_OPTION(option, opt, peephole_optimization); SET_COMPILE_OPTION(option, opt, tailcall_optimization); SET_COMPILE_OPTION(option, opt, specialized_instruction); SET_COMPILE_OPTION(option, opt, operands_unification); SET_COMPILE_OPTION(option, opt, instructions_unification); SET_COMPILE_OPTION(option, opt, stack_caching); SET_COMPILE_OPTION(option, opt, frozen_string_literal); SET_COMPILE_OPTION(option, opt, debug_frozen_string_literal); SET_COMPILE_OPTION(option, opt, coverage_enabled); "iseq.c", line 812: identifier redefined: flag current : unsigned long ... If the definition of flag is moved outside of the macro: VALUE flag; #define SET_COMPILE_OPTION(o, h, mem) \ { flag = rb_hash_aref((h), ID2SYM(rb_intern(#mem))); \ if (flag == Qtrue) { (o)->mem = 1; } \ else if (flag == Qfalse) { (o)->mem = 0; } \ } then iseq.c gets compiled. What's the correct fix for this macro? 2) After fixing the above error, the build progresses but fails in linking miniruby linking miniruby Undefined first referenced symbol in file .L13046 iseq.o It is not clear what .L13046 represents. Can any one please share how this issue can be resolved? Thanks.

2 1

[ruby-core:115710] [Ruby master Bug#20060] bundled_gems.rb is not working with Bootsnap
by hsbt (Hiroshi SHIBATA) 13 Dec '23

13 Dec '23

Issue #20060 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20060: bundled_gems.rb is not working with Bootsnap https://bugs.ruby-lang.org/issues/20060 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Addressed from https://github.com/ruby/ruby/pull/9163#issuecomment-1850924893 `bundled_gems.rb` of 3.3.0-rc1 couldn't handle full paths by Bootsnap. ``` $ rails new example (snip) rails importmap:install bin/rails aborted! ArgumentError: comparison of String with nil failed (ArgumentError) msg = " #{RUBY_VERSION < SINCE[gem] ? "will no longer be" : "is not"} part of the default gems since Ruby #{SINCE[gem]}." (snip) ``` It's working with DISABLE_BOOTSNAP=1. But we should resolve it with under the bootsnap. -- https://bugs.ruby-lang.org/

1 3

[ruby-core:115733] [Ruby master Feature#13383] [PATCH] Module#source_location
by matheusrich (Matheus Richard) 13 Dec '23

13 Dec '23

Issue #13383 has been updated by matheusrich (Matheus Richard). I want to bring this up again. This feature feels very natural to me, and it was surprising that `Module#source_locations` isn't implemented yet. What can we do to move this forward? ---------------------------------------- Feature #13383: [PATCH] Module#source_location https://bugs.ruby-lang.org/issues/13383#change-105666 * Author: koba789 (Hidekazu Kobayashi) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- # Abstract It can inspect where the module or class is defined. # Background In debugging or development an application, I usually want to find out where the class definition of using library. There is Method#source_location but I could not find **Class** easily. # Implementation In Github: https://github.com/ruby/ruby/pull/1562 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115197] [Ruby master Misc#19980] Is the Ruby 3.3 ABI frozen?
by mdalessio (Mike Dalessio) 13 Dec '23

13 Dec '23

Issue #19980 has been reported by mdalessio (Mike Dalessio). ---------------------------------------- Misc #19980: Is the Ruby 3.3 ABI frozen? https://bugs.ruby-lang.org/issues/19980 * Author: mdalessio (Mike Dalessio) * Status: Open * Priority: Normal ---------------------------------------- I'm a co-maintainer of [rake-compiler-dock](https://github.com/rake-compiler/rake-compiler-dock) which is used to build precompiled native packages for some gems, including nokogiri, sqlite3, grpc, re2, and ruby-magic. In the past, precompiled native gems generally released support for a new version of Ruby days or weeks after Ruby's release (for example, [Nokogiri v1.14.0 released on 2023-01-12](https://nokogiri.org/CHANGELOG.html)) In some cases, the lack of native gem support has slowed user adoption of the new version of Ruby. This year, I'd like to see native gems release Ruby 3.3 support before the final version is released. This will encourage testing of Ruby 3.3 previews and allow users to immediately upgrade to Ruby 3.3 final when it is released. To do that, I would like to cut a release of the rake-compiler-dock gem (and its [build containers](https://github.com/rake-compiler/rake-compiler-dock/pkgs/contai…) that supports Ruby 3.3 as soon as possible (I already have a feature branch mostly working based on 3.3.0_preview1 at https://github.com/rake-compiler/rake-compiler-dock/pull/105) Is the Ruby 3.3 ABI frozen now? If I build a native gem against Ruby 3.3.0_preview2, is there any reason to believe that it wouldn't work with Ruby 3.3 final when it is released? Thank you for any guidance you can provide. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:115727] [Ruby master Bug#19114] Calling TracePoint#enable multiple times causes TracePoint to be activated multiple times
by ivoanjo (Ivo Anjo) 13 Dec '23

13 Dec '23

Issue #19114 has been updated by ivoanjo (Ivo Anjo). Nice, thanks for fixing this one! 🙇 ---------------------------------------- Bug #19114: Calling TracePoint#enable multiple times causes TracePoint to be activated multiple times https://bugs.ruby-lang.org/issues/19114#change-105660 * Author: ivoanjo (Ivo Anjo) * Status: Closed * Priority: Normal * ruby -v: ruby 3.2.0preview2 (2022-09-09 master 35cfc9a3bb) [x86_64-darwin20] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Howdy 👋! I work for Datadog [on the `ddtrace` gem](https://github.com/DataDog/dd-trace-rb) and I found an issue with TracePoint. ### Background For tracking time spent in Garbage Collection on our Ruby profiler, we use a tracepoint. While doing some experiments around our code, I realized that enabling the same `TracePoint` more than once made it trigger multiple times. ### How to reproduce (Ruby version & script) This can be reproduced with any tracepoint: ```ruby puts RUBY_DESCRIPTION puts "Enabling tracepoint" tracepoint = TracePoint.new(:line) { |tp| p [tp.path, tp.lineno, tp.event] }.tap(&:enable) 5.times { tracepoint.enable } puts "Finished!" ``` ### Expectation and result This is the output of the above script: ``` ruby 3.2.0preview2 (2022-09-09 master 35cfc9a3bb) [x86_64-darwin20] Enabling tracepoint ["<internal:kernel>", 91, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["<internal:trace_point>", 213, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["triggertracepoint.rb", 5, :line] ["triggertracepoint.rb", 5, :line] ["triggertracepoint.rb", 5, :line] ["triggertracepoint.rb", 5, :line] ["triggertracepoint.rb", 5, :line] ["triggertracepoint.rb", 5, :line] Finished! ``` My expectation is that once enabled, a `TracePoint` fires only once for each event, regardless of how many times `TracePoint#enable` was called. Instead, I see it being called as many times as `#enable` was called. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115713] [Ruby master Bug#20061] test_free_on_exit_env_var failed with some cppflags
by znz (Kazuhiro NISHIYAMA) 12 Dec '23

12 Dec '23

Issue #20061 has been reported by znz (Kazuhiro NISHIYAMA). ---------------------------------------- Bug #20061: test_free_on_exit_env_var failed with some cppflags https://bugs.ruby-lang.org/issues/20061 * Author: znz (Kazuhiro NISHIYAMA) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-12-12T01:31:37Z master 73b43fffa1) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I use following `cppflags`, and `TestRubyOptions#test_free_on_exit_env_var` failed. ``` ../configure 'cppflags=-DUSE_RVARGC -DRUBY_DEBUG -DVM_CHECK_MODE=1 -DTRANSIENT_HEAP_CHECK_MODE -DRGENGC_CHECK_MODE -DENC_DEBUG -DUSE_RUBY_DEBUG_LOG=1' --prefix=$(rbenv root)/versions/master --with-baseruby=/usr/bin/ruby --disable-install-doc ``` It can reproduce using `miniruby`. ``` $ env RUBY_FREE_ON_EXIT=1 ./miniruby -e 0 ./miniruby: warning: Free on exit is experimental and may be unstable -e: [BUG] obj_free: RVALUE_MARKED(0x00007efe26a69010 [3LM ] T_CLASS (anon)) != FALSE ruby 3.3.0dev (2023-12-12T01:31:37Z master 73b43fffa1) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0001 p:0000 s:0003 E:0006b0 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /home/ubuntu/ruby/build/miniruby(rb_print_backtrace+0x14) [0x5563381d66a7] ../vm_dump.c:820 /home/ubuntu/ruby/build/miniruby(rb_vm_bugreport) ../vm_dump.c:1151 /home/ubuntu/ruby/build/miniruby(bug_report_end+0x0) [0x556337fc41ad] ../error.c:1042 /home/ubuntu/ruby/build/miniruby(rb_bug_without_die) ../error.c:1042 /home/ubuntu/ruby/build/miniruby(die+0x0) [0x556337eef35b] ../error.c:1050 /home/ubuntu/ruby/build/miniruby(rb_bug) ../error.c:1052 /home/ubuntu/ruby/build/miniruby(obj_free+0x6db) [0x556337fed3fb] ../gc.c:3551 /home/ubuntu/ruby/build/miniruby(rb_objspace_call_finalizer+0x3bb) [0x556337fed8db] ../gc.c:4692 /home/ubuntu/ruby/build/miniruby(rb_ec_finalize+0x2a) [0x556337fccf80] ../eval.c:168 /home/ubuntu/ruby/build/miniruby(rb_ec_cleanup) ../eval.c:260 /home/ubuntu/ruby/build/miniruby(ruby_run_node+0x6e) [0x556337fcf58e] ../eval.c:328 /home/ubuntu/ruby/build/miniruby(rb_main+0x21) [0x556337f0ff0b] ../main.c:39 /home/ubuntu/ruby/build/miniruby(main) ../main.c:58 /lib/x86_64-linux-gnu/libc.so.6(0x7efe2a5bad90) [0x7efe2a5bad90] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7efe2a5bae40] [0x556337f0ff55] -- Other runtime information ----------------------------------------------- * Process memory map: 556337ea6000-556337ee9000 r--p 00000000 00:39 4234136 /home/ubuntu/ruby/build/miniruby 556337ee9000-5563382fc000 r-xp 00043000 00:39 4234136 /home/ubuntu/ruby/build/miniruby 5563382fc000-5563384aa000 r--p 00456000 00:39 4234136 /home/ubuntu/ruby/build/miniruby 5563384aa000-5563384c1000 r--p 00603000 00:39 4234136 /home/ubuntu/ruby/build/miniruby 5563384c1000-5563384c2000 rw-p 0061a000 00:39 4234136 /home/ubuntu/ruby/build/miniruby 5563384c2000-5563384d8000 rw-p 00000000 00:00 0 55633a3d2000-55633a6dd000 rw-p 00000000 00:00 0 [heap] 7efe23be1000-7efe26710000 r--s 00000000 00:39 4234136 /home/ubuntu/ruby/build/miniruby 7efe26710000-7efe26720000 rw-p 00000000 00:00 0 7efe26812000-7efe26a30000 r--s 00000000 00:39 4191832 /usr/lib/x86_64-linux-gnu/libc.so.6 7efe26a30000-7efe26ad0000 rw-p 00000000 00:00 0 7efe26ad0000-7efe26ad1000 ---p 00000000 00:00 0 7efe26ad1000-7efe26b72000 rw-p 00000000 00:00 0 7efe26b72000-7efe26b73000 ---p 00000000 00:00 0 7efe26b73000-7efe26c14000 rw-p 00000000 00:00 0 7efe26c14000-7efe26c15000 ---p 00000000 00:00 0 7efe26c15000-7efe26cb6000 rw-p 00000000 00:00 0 7efe26cb6000-7efe26cb7000 ---p 00000000 00:00 0 7efe26cb7000-7efe26d58000 rw-p 00000000 00:00 0 7efe26d58000-7efe26d59000 ---p 00000000 00:00 0 7efe26d59000-7efe26dfa000 rw-p 00000000 00:00 0 7efe26dfa000-7efe26dfb000 ---p 00000000 00:00 0 7efe26dfb000-7efe26e9c000 rw-p 00000000 00:00 0 7efe26e9c000-7efe26e9d000 ---p 00000000 00:00 0 7efe26e9d000-7efe26f3e000 rw-p 00000000 00:00 0 7efe26f3e000-7efe26f3f000 ---p 00000000 00:00 0 7efe26f3f000-7efe26fe0000 rw-p 00000000 00:00 0 7efe26fe0000-7efe26fe1000 ---p 00000000 00:00 0 7efe26fe1000-7efe27082000 rw-p 00000000 00:00 0 7efe27082000-7efe27083000 ---p 00000000 00:00 0 7efe27083000-7efe27124000 rw-p 00000000 00:00 0 7efe27124000-7efe27125000 ---p 00000000 00:00 0 7efe27125000-7efe271c6000 rw-p 00000000 00:00 0 7efe271c6000-7efe271c7000 ---p 00000000 00:00 0 7efe271c7000-7efe27268000 rw-p 00000000 00:00 0 7efe27268000-7efe27269000 ---p 00000000 00:00 0 7efe27269000-7efe2730a000 rw-p 00000000 00:00 0 7efe2730a000-7efe2730b000 ---p 00000000 00:00 0 7efe2730b000-7efe273ac000 rw-p 00000000 00:00 0 7efe273ac000-7efe273ad000 ---p 00000000 00:00 0 7efe273ad000-7efe2744e000 rw-p 00000000 00:00 0 7efe2744e000-7efe2744f000 ---p 00000000 00:00 0 7efe2744f000-7efe274f0000 rw-p 00000000 00:00 0 7efe274f0000-7efe274f1000 ---p 00000000 00:00 0 7efe274f1000-7efe27592000 rw-p 00000000 00:00 0 7efe27592000-7efe27593000 ---p 00000000 00:00 0 7efe27593000-7efe27634000 rw-p 00000000 00:00 0 7efe27634000-7efe27635000 ---p 00000000 00:00 0 7efe27635000-7efe276d6000 rw-p 00000000 00:00 0 7efe276d6000-7efe276d7000 ---p 00000000 00:00 0 7efe276d7000-7efe27778000 rw-p 00000000 00:00 0 7efe27778000-7efe27779000 ---p 00000000 00:00 0 7efe27779000-7efe2781a000 rw-p 00000000 00:00 0 7efe2781a000-7efe2781b000 ---p 00000000 00:00 0 7efe2781b000-7efe278bc000 rw-p 00000000 00:00 0 7efe278bc000-7efe278bd000 ---p 00000000 00:00 0 7efe278bd000-7efe2795e000 rw-p 00000000 00:00 0 7efe2795e000-7efe2795f000 ---p 00000000 00:00 0 7efe2795f000-7efe27a00000 rw-p 00000000 00:00 0 7efe27a00000-7efe27a01000 ---p 00000000 00:00 0 7efe27a01000-7efe27aa2000 rw-p 00000000 00:00 0 7efe27aa2000-7efe27aa3000 ---p 00000000 00:00 0 7efe27aa3000-7efe27b44000 rw-p 00000000 00:00 0 7efe27b44000-7efe27b45000 ---p 00000000 00:00 0 7efe27b45000-7efe27be6000 rw-p 00000000 00:00 0 7efe27be6000-7efe27be7000 ---p 00000000 00:00 0 7efe27be7000-7efe27c88000 rw-p 00000000 00:00 0 7efe27c88000-7efe27c89000 ---p 00000000 00:00 0 7efe27c89000-7efe27d2a000 rw-p 00000000 00:00 0 7efe27d2a000-7efe27d2b000 ---p 00000000 00:00 0 7efe27d2b000-7efe27dcc000 rw-p 00000000 00:00 0 7efe27dcc000-7efe27dcd000 ---p 00000000 00:00 0 7efe27dcd000-7efe27e6e000 rw-p 00000000 00:00 0 7efe27e6e000-7efe27e6f000 ---p 00000000 00:00 0 7efe27e6f000-7efe27f20000 rw-p 00000000 00:00 0 7efe27f2f000-7efe27f30000 ---p 00000000 00:00 0 7efe27f30000-7efe28780000 rw-p 00000000 00:00 0 7efe2878f000-7efe2a140000 rw-p 00000000 00:00 0 7efe2a144000-7efe2a245000 rw-p 00000000 00:00 0 7efe2a245000-7efe2a24c000 r--s 00000000 00:39 4192098 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache 7efe2a24c000-7efe2a2a3000 r--p 00000000 00:39 4193355 /usr/lib/locale/C.utf8/LC_CTYPE 7efe2a2a3000-7efe2a58c000 r--p 00000000 00:39 4192959 /usr/lib/locale/locale-archive 7efe2a58c000-7efe2a591000 rw-p 00000000 00:00 0 7efe2a591000-7efe2a5b9000 r--p 00000000 00:39 4191832 /usr/lib/x86_64-linux-gnu/libc.so.6 7efe2a5b9000-7efe2a74e000 r-xp 00028000 00:39 4191832 /usr/lib/x86_64-linux-gnu/libc.so.6 7efe2a74e000-7efe2a7a6000 r--p 001bd000 00:39 4191832 /usr/lib/x86_64-linux-gnu/libc.so.6 7efe2a7a6000-7efe2a7aa000 r--p 00214000 00:39 4191832 /usr/lib/x86_64-linux-gnu/libc.so.6 7efe2a7aa000-7efe2a7ac000 rw-p 00218000 00:39 4191832 /usr/lib/x86_64-linux-gnu/libc.so.6 7efe2a7ac000-7efe2a7b9000 rw-p 00000000 00:00 0 7efe2a7b9000-7efe2a7bc000 r--p 00000000 00:39 3583519 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7efe2a7bc000-7efe2a7d3000 r-xp 00003000 00:39 3583519 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7efe2a7d3000-7efe2a7d7000 r--p 0001a000 00:39 3583519 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7efe2a7d7000-7efe2a7d8000 r--p 0001d000 00:39 3583519 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7efe2a7d8000-7efe2a7d9000 rw-p 0001e000 00:39 3583519 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7efe2a7d9000-7efe2a7e7000 r--p 00000000 00:39 4191835 /usr/lib/x86_64-linux-gnu/libm.so.6 7efe2a7e7000-7efe2a863000 r-xp 0000e000 00:39 4191835 /usr/lib/x86_64-linux-gnu/libm.so.6 7efe2a863000-7efe2a8be000 r--p 0008a000 00:39 4191835 /usr/lib/x86_64-linux-gnu/libm.so.6 7efe2a8be000-7efe2a8bf000 r--p 000e4000 00:39 4191835 /usr/lib/x86_64-linux-gnu/libm.so.6 7efe2a8bf000-7efe2a8c0000 rw-p 000e5000 00:39 4191835 /usr/lib/x86_64-linux-gnu/libm.so.6 7efe2a8c0000-7efe2a8c2000 r--p 00000000 00:39 12895 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7efe2a8c2000-7efe2a8d6000 r-xp 00002000 00:39 12895 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7efe2a8d6000-7efe2a8ef000 r--p 00016000 00:39 12895 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7efe2a8ef000-7efe2a8f0000 ---p 0002f000 00:39 12895 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7efe2a8f0000-7efe2a8f1000 r--p 0002f000 00:39 12895 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7efe2a8f1000-7efe2a8f2000 rw-p 00030000 00:39 12895 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7efe2a8f2000-7efe2a8fa000 rw-p 00000000 00:00 0 7efe2a8fa000-7efe2a904000 r--p 00000000 00:39 13002 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 7efe2a904000-7efe2a963000 r-xp 0000a000 00:39 13002 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 7efe2a963000-7efe2a97a000 r--p 00069000 00:39 13002 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 7efe2a97a000-7efe2a97b000 r--p 0007f000 00:39 13002 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 7efe2a97b000-7efe2a97c000 rw-p 00080000 00:39 13002 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 7efe2a97c000-7efe2a97e000 r--p 00000000 00:39 13365 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 7efe2a97e000-7efe2a98f000 r-xp 00002000 00:39 13365 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 7efe2a98f000-7efe2a995000 r--p 00013000 00:39 13365 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 7efe2a995000-7efe2a996000 ---p 00019000 00:39 13365 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 7efe2a996000-7efe2a997000 r--p 00019000 00:39 13365 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 7efe2a997000-7efe2a998000 rw-p 0001a000 00:39 13365 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 7efe2a99e000-7efe2a9a0000 rw-p 00000000 00:00 0 7efe2a9a0000-7efe2a9a2000 r--p 00000000 00:39 4191829 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7efe2a9a2000-7efe2a9cc000 r-xp 00002000 00:39 4191829 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7efe2a9cc000-7efe2a9d7000 r--p 0002c000 00:39 4191829 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7efe2a9d8000-7efe2a9da000 r--p 00037000 00:39 4191829 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7efe2a9da000-7efe2a9dc000 rw-p 00039000 00:39 4191829 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7ffdc11f0000-7ffdc19ef000 rw-p 00000000 00:00 0 [stack] 7ffdc19f7000-7ffdc19fb000 r--p 00000000 00:00 0 [vvar] 7ffdc19fb000-7ffdc19fd000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] Aborted (core dumped) ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115569] [Ruby master Misc#20035] Command-line settings move from parser to compiler
by kddnewton (Kevin Newton) 12 Dec '23

12 Dec '23

Issue #20035 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #20035: Command-line settings move from parser to compiler https://bugs.ruby-lang.org/issues/20035 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- Right now, when you pass `-n`, `-p`, `-l`, or `-a`, these options are all passed to the parser to manipulate the parse tree into giving you the desired behavior. For example: $ ruby --dump=parsetree -p -e "foo" ``` ruby ########################################################### ## Do NOT use this node dump for any purpose other than ## ## debug and research. Compatibility is not guaranteed. ## ########################################################### # @ NODE_SCOPE (id: 1, line: 1, location: (1,0)-(1,3)) # +- nd_tbl: (empty) # +- nd_args: # | (null node) # +- nd_body: # @ NODE_WHILE (id: 10, line: 1, location: (1,0)-(1,0)) # +- nd_state: 1 (while-end) # +- nd_cond: # | @ NODE_FCALL (id: 9, line: 1, location: (1,0)-(1,0)) # | +- nd_mid: :gets # | +- nd_args: # | @ NODE_LIST (id: 8, line: 1, location: (1,0)-(1,0)) # | +- nd_alen: 1 # | +- nd_head: # | | @ NODE_GVAR (id: 7, line: 1, location: (1,0)-(1,0)) # | | +- nd_entry: :$/ # | +- nd_next: # | (null node) # +- nd_body: # @ NODE_BLOCK (id: 5, line: 1, location: (1,0)-(1,0)) # +- nd_head (1): # | @ NODE_VCALL (id: 0, line: 1, location: (1,0)-(1,3))* # | +- nd_mid: :foo # +- nd_head (2): # @ NODE_FCALL (id: 4, line: 1, location: (1,0)-(1,0)) # +- nd_mid: :print # +- nd_args: # @ NODE_LIST (id: 3, line: 1, location: (1,0)-(1,0)) # +- nd_alen: 1 # +- nd_head: # | @ NODE_GVAR (id: 2, line: 1, location: (1,0)-(1,0)) # | +- nd_entry: :$_ # +- nd_next: # (null node) ``` Could this mutation be moved into the compiler? That way it could be shared by prism, but also because it would make it less confusing when people are running `--dump=parsetree` as to why a loop is being inserted. -- https://bugs.ruby-lang.org/

2 4