- ruby-dev - ml.ruby-lang.org

[ruby-dev:52043] [Ruby master Bug#17925] Pattern matching syntax using semicolon one-line
by yui-knk (Kaneko Yuichiro) 04 Sep '23

04 Sep '23

Issue #17925 has been updated by yui-knk (Kaneko Yuichiro). It's possible https://github.com/yui-knk/ruby/tree/bugs_17925. I think this is not limitaion but the matter of choice. Currently `expr` is expected after `case` therefore `expression in 42` is interpreted as `expr`. For example ```ruby case expression in 42 in true in false end ``` Before the change, this is interpreted as ```ruby case (expression in 42) in true in false end ``` After the change, this is interpreted as ```ruby case expression in 42 in true in false end ``` # Impact ## For `case ... in` As shown above, this will change the behavior of current codes. Before: ```ruby expression = 42 case expression in 42 in true p :t in false p :f end #=> :t ``` ```ruby expression = 421 case expression in 42 in true p :t in false p :f end #=> :f ``` After: ```ruby expression = 42 case expression in 42 in true p :t in false p :f end #=> nothing printed, because body for 42 is empty ``` ```ruby expression = 421 case expression in 42 in true p :t in false p :f end #=> 421 (NoMatchingPatternError) # because nothing matches ``` ## For `case ... when` Before this change, this is valid ```ruby case expression in 42 when true p :t when false p :f end ``` However after this change, it's invalid ```ruby case expression in 42 when true p :t when false p :f end # test2.rb:2: syntax error, unexpected `when' (SyntaxError) # when true # ^~~~ ``` Impact on `case ... when` is inevitable because new grammar recognizes this is `case ... in` when third symbol (`in`) appears. ## New exception `expr` appears other place of the grammar. For example, `if expr ...`, `while expr ...` and so on. This change introduces an exception that you can write one line pattern matching after `if`, `unless`, `while`, `until` and so on but you can't after `case`. # Conclusion * This a matter of choice not limitaion * New grammar introduces incompatibility. It changes the behavior of `case ... in` and breaks `case ... when` * It introduces an exceptional rule to the grammar * As a reporter says, there is workaround to add `;` after `expression` `expression in 42` always returns `true` or `false` therefore it might be useless for `case`. Howerver we need to consider such impacts and benefits before decision making. # Note Impact on `case ... when` can be found as Shift/Reduce conflict. In this state, shift derives `case ... when`, on the other hand reduce derives `case ... in`. https://github.com/yui-knk/ruby/tree/bugs_17925_2 ``` State 394 shift/reduce conflict on token "`in'": 60 expr0: arg • 71 expr: arg • "`in'" @7 @8 p_top_expr_body First example: $@1 k_case arg • "`in'" @7 @8 p_top_expr_body opt_terms @19 case_body k_end "=>" @5 @6 p_top_expr_body opt_terms Shift derivation program ↳ 2: $@1 top_compstmt ↳ 3: top_stmts opt_terms ↳ 5: top_stmt ↳ 7: stmt ↳ 37: expr ↳ 68: arg "=>" @5 @6 p_top_expr_body ↳ 269: primary ↳ 358: k_case expr_value opt_terms @19 case_body k_end ↳ 78: expr ↳ 71: arg • "`in'" @7 @8 p_top_expr_body Second example: $@1 k_case arg • opt_terms "`in'" @38 @39 p_top_expr then $@40 compstmt p_cases k_end '[' opt_call_args rbracket "operator-assignment" lex_ctxt command_rhs opt_terms "end-of-input" Reduce derivation $accept ↳ 0: program "end-of-input" ↳ 2: $@1 top_compstmt ↳ 3: top_stmts opt_terms ↳ 5: top_stmt ↳ 7: stmt ↳ 32: command_asgn ↳ 41: primary_value '[' opt_call_args rbracket "operator-assignment" lex_ctxt command_rhs ↳ 377: primary ↳ 361: k_case expr_value0 opt_terms p_case_body k_end ↳ 77: expr0 ↳ 500: "`in'" @38 @39 p_top_expr then $@40 compstmt p_cases ↳ 60: arg • ``` ---------------------------------------- Bug #17925: Pattern matching syntax using semicolon one-line https://bugs.ruby-lang.org/issues/17925#change-104453 * Author: koic (Koichi ITO) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Summary There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior? ```console % ruby -v ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] % ruby -ce 'case expression when 42; end' Syntax OK % ruby -ce 'case expression in 42; end' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! -e:1: syntax error, unexpected `end', expecting `when' case expression in 42; end ``` So, I have two concerns. - Since the pattern matching syntax is different from `case ... when`,　can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`? - Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right? This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1. ## Additional Information NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax. ``` % ruby -ce 'expression in 42' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! Syntax OK ``` NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit. ``` % ruby -e ruby -ce 'case expression; in 42; end' Syntax OK ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-dev:52042] [Ruby master Bug#17925] Pattern matching syntax using semicolon one-line
by kddnewton (Kevin Newton) 25 Aug '23

25 Aug '23

Issue #17925 has been updated by kddnewton (Kevin Newton). This is interesting. It surfaces and incompatibility we have. I didn't realize Ruby didn't allow this, so YARP allows `case expression in 42; end` to parse as expected by the OP here. If `parse.y` can't support this, I will need to explicitly disallow this in YARP. ---------------------------------------- Bug #17925: Pattern matching syntax using semicolon one-line https://bugs.ruby-lang.org/issues/17925#change-104372 * Author: koic (Koichi ITO) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Summary There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior? ```console % ruby -v ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] % ruby -ce 'case expression when 42; end' Syntax OK % ruby -ce 'case expression in 42; end' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! -e:1: syntax error, unexpected `end', expecting `when' case expression in 42; end ``` So, I have two concerns. - Since the pattern matching syntax is different from `case ... when`,　can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`? - Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right? This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1. ## Additional Information NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax. ``` % ruby -ce 'expression in 42' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! Syntax OK ``` NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit. ``` % ruby -e ruby -ce 'case expression; in 42; end' Syntax OK ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-dev:52041] [Ruby master Bug#17925] Pattern matching syntax using semicolon one-line
by nobu (Nobuyoshi Nakada) 25 Aug '23

25 Aug '23

Issue #17925 has been updated by nobu (Nobuyoshi Nakada). I thought it a trade-off. To allow the statement, one-line pattern matching is not allowed there. But it returns `true`/`false` only and may be useless for `case`. ---------------------------------------- Bug #17925: Pattern matching syntax using semicolon one-line https://bugs.ruby-lang.org/issues/17925#change-104322 * Author: koic (Koichi ITO) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Summary There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior? ```console % ruby -v ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] % ruby -ce 'case expression when 42; end' Syntax OK % ruby -ce 'case expression in 42; end' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! -e:1: syntax error, unexpected `end', expecting `when' case expression in 42; end ``` So, I have two concerns. - Since the pattern matching syntax is different from `case ... when`,　can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`? - Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right? This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1. ## Additional Information NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax. ``` % ruby -ce 'expression in 42' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! Syntax OK ``` NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit. ``` % ruby -e ruby -ce 'case expression; in 42; end' Syntax OK ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-dev:52040] [Ruby master Bug#17925] Pattern matching syntax using semicolon one-line
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17925 has been updated by jeremyevans0 (Jeremy Evans). @kddnewton Is this possible to fix in YARP? @yui-knk Is this possible to fix in parse.y/lrama? ---------------------------------------- Bug #17925: Pattern matching syntax using semicolon one-line https://bugs.ruby-lang.org/issues/17925#change-104311 * Author: koic (Koichi ITO) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Summary There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior? ```console % ruby -v ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] % ruby -ce 'case expression when 42; end' Syntax OK % ruby -ce 'case expression in 42; end' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! -e:1: syntax error, unexpected `end', expecting `when' case expression in 42; end ``` So, I have two concerns. - Since the pattern matching syntax is different from `case ... when`,　can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`? - Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right? This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1. ## Additional Information NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax. ``` % ruby -ce 'expression in 42' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! Syntax OK ``` NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit. ``` % ruby -e ruby -ce 'case expression; in 42; end' Syntax OK ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-dev:52038] [Ruby master Bug#8782] Don't set rl_getc_function on editline
by jeremyevans0 (Jeremy Evans) 22 Aug '23

22 Aug '23

Issue #8782 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Assigned to Closed Backport deleted (1.9.3: UNKNOWN, 2.0.0: UNKNOWN) Readline support was removed in commit:59fd67fc3d405e529e038172e769ff20a8fb5535. If this is still an issue, please file it upstream https://github.com/ruby/readline-ext ---------------------------------------- Bug #8782: Don't set rl_getc_function on editline https://bugs.ruby-lang.org/issues/8782#change-104205 * Author: naruse (Yui NARUSE) * Status: Closed * Priority: Normal * Assignee: kouji (Kouji Takao) * ruby -v: ruby 2.1.0dev (2013-08-12 trunk 42528) [x86_64-darwin12.4.0] ---------------------------------------- r42402 以来 OS X 等の editline 環境では #define rl_getc(f) EOF が使われるようになってしまって残念なことになっていたわけですが、そもそも editline の readline wrapper は non ASCII に対応していません。 (editline 自体には UTF-8 のみの対応が入ったが、readline wrapper は src/readline.c の _getc_function を経由するので non ASCII は化ける) ので、いっそ rl_getc_function を使わないようにしてはどうでしょう。以下のようなパッチを当てると、readline なしの OS X の irb で日本語が使えるようになります。 diff --git a/ext/readline/extconf.rb b/ext/readline/extconf.rb index 0b121c1..bc0ee77 100644 --- a/ext/readline/extconf.rb +++ b/ext/readline/extconf.rb @@ -94,4 +94,5 @@ readline.have_func("clear_history") readline.have_func("rl_redisplay") readline.have_func("rl_insert_text") readline.have_func("rl_delete_text") +readline.have_func("el_init") create_makefile("readline") diff --git a/ext/readline/readline.c b/ext/readline/readline.c index 0f76d1a..85109f0 100644 --- a/ext/readline/readline.c +++ b/ext/readline/readline.c @@ -130,12 +130,7 @@ static VALUE readline_instream; static VALUE readline_outstream; #if defined HAVE_RL_GETC_FUNCTION - -#ifndef HAVE_RL_GETC -#define rl_getc(f) EOF -#endif - -static int readline_getc(FILE *); +# ifndef HAVE_EL_INIT static int readline_getc(FILE *input) { @@ -187,6 +182,7 @@ readline_getc(FILE *input) #endif return FIX2INT(c); } +# endif #elif defined HAVE_RL_EVENT_HOOK #define BUSY_WAIT 0 @@ -1771,7 +1767,9 @@ Init_readline() /* libedit check rl_getc_function only when rl_initialize() is called, */ /* and using_history() call rl_initialize(). */ /* This assignment should be placed before using_history() */ +# ifndef HAVE_EL_INIT rl_getc_function = readline_getc; +# endif #elif defined HAVE_RL_EVENT_HOOK rl_event_hook = readline_event; #endif -- https://bugs.ruby-lang.org/

1 0

[ruby-dev:52033] [Ruby master Bug#14387] Ruby 2.5 を Alpine Linux で実行すると比較的浅めで SystemStackError 例外になる
by ojab (ojab ojab) 01 Jan '23

01 Jan '23

Issue #14387 has been updated by ojab (ojab ojab). Any update on this? ---------------------------------------- Bug #14387: Ruby 2.5 を Alpine Linux で実行すると比較的浅めで SystemStackError 例外になる https://bugs.ruby-lang.org/issues/14387#change-100931 * Author: koshigoe (Masataka SUZUKI) * Status: Open * Priority: Normal * ruby -v: ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux-musl] * Backport: 2.3: DONTNEED, 2.4: DONTNEED, 2.5: REQUIRED ---------------------------------------- CircleCI で Alpine Linux を使って Ruby 2.5.0 で Rubocop を実行した時に遭遇した例外です(Ruby 2.4.3 では発生しませんでした)。 Ruby のバージョンによって、再帰が止められるまでの回数に大きな違いがあるのはなぜでしょうか？これは、意図された挙動なのか、Ruby の変更によるものでは無く Alpine Linux 固有の問題なのか、教えていただく事は可能でしょうか？ Alpine Linux の Tread stack size が比較的小さい事で、Ruby 2.5.0 からこのような挙動になったのでしょうか？ https://wiki.musl-libc.org/functional-differences-from-glibc.html#Thread-st… ## 再現問題の再現のため、以下の様な再帰するコードを実行します。 ~~~ ruby # test.rb n = 100000 res = {} 1.upto(n).to_a.inject(res) do |r, i| r[i] = {} end def f(x) x.each_value { |v| f(v) } end f(res) ~~~ Ruby 2.4.3 で実行した場合、 10061 levels で例外があがりました。 ~~~ % docker container run \ -v (pwd):/mnt/my --rm \ ruby:2.4.3-alpine3.7 \ ruby -v /mnt/my/test.rb ruby 2.4.3p205 (2017-12-14 revision 61247) [x86_64-linux-musl] /mnt/my/test.rb:9:in `each_value': stack level too deep (SystemStackError) from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' ... 10061 levels... from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:12:in `<main>' ``` 一方で Ruby 2.5.0 で実行した場合、 134 level で例外があがりました。 ``` % docker container run \ -v (pwd):/mnt/my --rm \ test/ruby:trunk-alpine3.7 \ ruby -v /mnt/my/test.rb ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux-musl] /mnt/my/test.rb:9:in `each_value': stack level too deep (SystemStackError) from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' ... 134 levels... from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:12:in `<main>' ``` また、Ruby trunk で実行した場合は 2.5.0 同等の結果になりました。 ``` ruby 2.6.0dev (2018-01-24 trunk 62017) [x86_64-linux-musl] /mnt/my/test.rb:9:in `each_value': stack level too deep (SystemStackError) from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' ... 134 levels... from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:12:in `<main>' ``` ※ trunk の Docker イメージを作った際の Dockerfile は以下。 https://gist.github.com/koshigoe/509be02a3580cdfc7a2cc45a4e6e44c5 ---Files-------------------------------- 0001-thread_pthread.c-make-get_main_stack-portable-on-lin.patch (2.61 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-dev:52032] [Ruby master Bug#18024] Ractor crashes when connections are closed in multiple Ractors
by niku (niku _) 27 Dec '22

27 Dec '22

Issue #18024 has been updated by niku (niku _). I also couldn't reproduce it on m2 mac with both ruby versions 3.0.0 which is reported and 3.2.0 the latest. I hope it helps. ``` ~/src/confirm_bugs.ruby-lang.org/18024 () asdf local ruby 3.0.0 ~/src/confirm_bugs.ruby-lang.org/18024 () ruby --version ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [arm64-darwin22] ~/src/confirm_bugs.ruby-lang.org/18024 () ruby description.rb <internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. "Starting a sender" "Worker|0 Data: yay" "Worker|0 Data: yay" "Worker|0 Data: yay" "Worker|1 Data: yay" "Worker|1 Data: yay" "Worker|1 Data: yay" "Worker|0 Data: yay" "Worker|0 Data: yay" "Worker|1 Data: yay" "Worker|0 Data: yay" ^C<internal:ractor>:694:in `take': Interrupt from description.rb:35:in `block in <main>' from description.rb:35:in `each' from description.rb:35:in `<main>' ~/src/confirm_bugs.ruby-lang.org/18024 () asdf local ruby 3.2.0 ~/src/confirm_bugs.ruby-lang.org/18024 () ruby --version ruby 3.2.0 (2022-12-25 revision a528908271) [arm64-darwin22] ~/src/confirm_bugs.ruby-lang.org/18024 () ruby description.rb description.rb:9: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. "Starting a sender" "Worker|0 Data: yay" "Worker|0 Data: yay" "Worker|0 Data: yay" "Worker|0 Data: yay" "Worker|0 Data: yay" "Worker|1 Data: yay" "Worker|0 Data: yay" "Worker|1 Data: yay" "Worker|1 Data: yay" "Worker|0 Data: yay" ^C<internal:ractor>:698:in `take': Interrupt from description.rb:35:in `block in <main>' from description.rb:35:in `each' from description.rb:35:in `<main>' ``` ---------------------------------------- Bug #18024: Ractor crashes when connections are closed in multiple Ractors https://bugs.ruby-lang.org/issues/18024#change-100818 * Author: tagomoris (Satoshi TAGOMORI) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [arm64-darwin20] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- When multiple Ractors will accept and close connections, that script caused the crash shown below. This pattern is taken when we want to distribute the overhead of `accept` to multiple CPU cores. Script: ``` require 'socket' try_times = 10 worker_num = 2 listener = TCPServer.new("127.0.0.1", 8228) listener.listen(100) workers = worker_num.times.map do |i| Ractor.new(i, listener.dup) do |index, sock| while conn = sock.accept begin data = conn.read p "Worker|#{index} Data: #{data}" conn.close rescue => e p "Worker|#{index} #{e.full_message}" end end rescue => e $stderr.puts "Error, worker#{index}: #{e.full_message}" end end p "Starting a sender" sender = Ractor.new(try_times) do |tries| tries.times.each do s = TCPSocket.new("127.0.0.1", 8228) s.write("yay") ensure s.close rescue nil end end sender.take workers.each{|w| w.take} p "End" ``` Crash report: ``` <internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. "Starting a sender" "Worker|1 Data: yay" snippets/ractor_accept.rb:30: [BUG] Bus Error at 0x00000014000001f5 ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [arm64-darwin20] -- Crash Report log information -------------------------------------------- See Crash Report log file under the one of following: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0006 p:---- s:0023 e:000022 CFUNC :close c:0005 p:0028 s:0019 e:000017 BLOCK snippets/ractor_accept.rb:30 [FINISH] c:0004 p:---- s:0014 e:000013 CFUNC :times c:0003 p:---- s:0011 e:000010 CFUNC :each c:0002 p:0008 s:0007 e:000006 BLOCK snippets/ractor_accept.rb:26 [FINISH] c:0001 p:---- s:0003 e:000002 (none) [FINISH] -- Ruby level backtrace information ---------------------------------------- snippets/ractor_accept.rb:26:in `block in <main>' snippets/ractor_accept.rb:26:in `each' snippets/ractor_accept.rb:26:in `times' snippets/ractor_accept.rb:30:in `block (2 levels) in <main>' snippets/ractor_accept.rb:30:in `close' -- Other runtime information ----------------------------------------------- * Loaded script: snippets/ractor_accept.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 rational.so 3 complex.so 4 ruby2_keywords.rb 5 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 6 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/trans/transdb.bundle 7 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/rbconfig.rb 8 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/compatibility.rb 9 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/defaults.rb 10 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/deprecate.rb 11 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/errors.rb 12 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/exceptions.rb 13 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/basic_specification.rb 14 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/stub_specification.rb 15 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/text.rb 16 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/user_interaction.rb 17 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/specification_policy.rb 18 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/util/list.rb 19 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/platform.rb 20 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/version.rb 21 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/requirement.rb 22 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/specification.rb 23 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/util.rb 24 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/dependency.rb 25 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/core_ext/kernel_gem.rb 26 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/monitor.bundle 27 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/monitor.rb 28 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb 29 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/core_ext/kernel_warn.rb 30 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems.rb 31 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/path_support.rb 32 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/version.rb 33 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/core_ext/name_error.rb 34 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/levenshtein.rb 35 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/jaro_winkler.rb 36 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/spell_checker.rb 37 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/spell_checkers/name_error_checkers/class_name_checker.rb 38 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/spell_checkers/name_error_checkers/variable_name_checker.rb 39 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/spell_checkers/name_error_checkers.rb 40 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/spell_checkers/method_name_checker.rb 41 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/spell_checkers/key_error_checker.rb 42 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/spell_checkers/null_checker.rb 43 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/tree_spell_checker.rb 44 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/spell_checkers/require_path_checker.rb 45 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/formatters/plain_formatter.rb 46 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean.rb 47 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/socket.bundle 48 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/io/wait.bundle 49 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/socket.rb * Process memory map: 1042f8000-1042fc000 r-x /Users/tagomoris/.rbenv/versions/3.0.0/bin/ruby 1042fc000-104300000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/bin/ruby 104300000-104304000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/bin/ruby 104304000-104308000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/bin/ruby 104308000-104310000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104310000-104314000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104314000-104318000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104318000-10431c000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 10431c000-104320000 --- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104320000-104328000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104328000-10432c000 --- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 10432c000-104330000 --- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104330000-104338000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104338000-10433c000 --- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 10433c000-104340000 --- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104340000-104348000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104348000-10434c000 --- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 10434c000-104350000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104350000-104354000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104354000-104394000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104394000-104398000 r-x /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104398000-10439c000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 10439c000-1043a0000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 1043a0000-1043a4000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 1043a4000-1043a8000 r-x /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/trans/transdb.bundle 1043a8000-1043ac000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/trans/transdb.bundle 1043ac000-1043b0000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/trans/transdb.bundle 1043b0000-1043b4000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/trans/transdb.bundle 1043b4000-1043b8000 r-x /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/monitor.bundle 1043b8000-1043bc000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/monitor.bundle 1043bc000-1043c0000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/monitor.bundle 1043c0000-1043c4000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/monitor.bundle 1043c4000-1043e8000 r-x /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/socket.bundle 1043e8000-1043ec000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/socket.bundle 1043ec000-1043f0000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/socket.bundle 1043f0000-104400000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/socket.bundle 104400000-104404000 r-x /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/io/wait.bundle 104404000-104408000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/io/wait.bundle 104408000-10440c000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/io/wait.bundle 10440c000-104410000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/io/wait.bundle 104568000-1045e8000 r-x /usr/lib/dyld 1045e8000-1045f0000 r-- /usr/lib/dyld 1045f0000-1045f4000 rw- /usr/lib/dyld 1045f4000-104628000 rw- /usr/lib/dyld 104628000-10466c000 r-- /usr/lib/dyld 10466c000-104670000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/libruby.3.0.dylib 104670000-104974000 r-x /Users/tagomoris/.rbenv/versions/3.0.0/lib/libruby.3.0.dylib 104974000-10497c000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/libruby.3.0.dylib 10497c000-104980000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/libruby.3.0.dylib 104980000-10498c000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/libruby.3.0.dylib 10498c000-104a7c000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/libruby.3.0.dylib 104a7c000-104a80000 --- 104a80000-104b24000 rw- 104b24000-104b28000 --- 104b28000-104bcc000 rw- 104bcc000-104bd0000 --- 104bd0000-104c74000 rw- 104c74000-104c78000 --- 104c78000-104d1c000 rw- 104d1c000-104d20000 --- 104d20000-104dc4000 rw- 104dc4000-104dc8000 --- 104dc8000-104e6c000 rw- 104e6c000-104e70000 --- 104e70000-104f14000 rw- 104f14000-104f18000 --- 104f18000-104fbc000 rw- 104fbc000-104fc0000 --- 104fc0000-105064000 rw- 105064000-105068000 --- 105068000-10510c000 rw- 10510c000-105110000 --- 105110000-1051b4000 rw- 1051b4000-1051b8000 --- 1051b8000-10525c000 rw- 10525c000-105260000 --- 105260000-105304000 rw- 105304000-105308000 --- 105308000-1053ac000 rw- 1053ac000-1053b0000 --- 1053b0000-105454000 rw- 105454000-105458000 --- 105458000-1054fc000 rw- 1054fc000-105500000 --- 105500000-1055a4000 rw- 1055a4000-1055a8000 --- 1055a8000-10564c000 rw- 10564c000-105650000 --- 105650000-1056f4000 rw- 1056f4000-1056f8000 --- 1056f8000-10579c000 rw- 10579c000-1057a0000 --- 1057a0000-105844000 rw- 105844000-105848000 --- 105848000-1058ec000 rw- 1058ec000-1058f0000 --- 1058f0000-105994000 rw- 105994000-105998000 --- 105998000-105a3c000 rw- 105a3c000-105a40000 --- 105a40000-105ae4000 rw- 105ae4000-105ae8000 --- 105ae8000-105b8c000 rw- 105b8c000-105b90000 --- 105b90000-105c34000 rw- 105c34000-105c38000 --- 105c38000-105cdc000 rw- 105cdc000-105ce0000 --- 105ce0000-105d84000 rw- 105d84000-105d88000 --- 105d88000-105e2c000 rw- 105e2c000-105e30000 --- 105e30000-105ed4000 rw- 105ed4000-105ed8000 --- 105ed8000-105f7c000 rw- 131e00000-131f00000 rw- 132000000-132800000 rw- 132800000-133000000 rw- 138000000-138800000 rw- 138800000-139000000 rw- 139000000-139800000 rw- 139800000-13a000000 rw- 13a000000-13a800000 rw- 13a800000-13b000000 rw- 13b000000-13b800000 rw- 13b800000-13c000000 rw- 13c000000-13c800000 rw- 13c800000-13d000000 rw- 13d000000-13d800000 rw- 13d800000-13e000000 rw- 13e000000-13e800000 rw- 13e800000-13f000000 rw- 13f000000-13f800000 rw- 13f800000-140000000 rw- 141e00000-141f00000 rw- 141f00000-142000000 rw- 142000000-142800000 rw- 148000000-148800000 rw- 148800000-149000000 rw- 149000000-149800000 rw- 149800000-14a000000 rw- 14a000000-14a800000 rw- 14a800000-14b000000 rw- 14b000000-14b800000 rw- 14b800000-14c000000 rw- 14c000000-14c800000 rw- 14c800000-14d000000 rw- 14d000000-14d800000 rw- 14d800000-14e000000 rw- 14e000000-14e800000 rw- 14e800000-14f000000 rw- 14f000000-14f800000 rw- 14f800000-150000000 rw- 151e00000-151f00000 rw- 151f00000-152000000 rw- 152000000-152800000 rw- 152800000-153000000 rw- 153000000-155000000 rw- 155000000-155004000 rw- 155100000-155200000 rw- 158000000-158800000 rw- 158800000-159000000 rw- 159000000-159800000 rw- 159800000-15a000000 rw- 15a000000-15a800000 rw- 15a800000-15b000000 rw- 15b000000-15b800000 rw- 15b800000-15c000000 rw- 15c000000-15c800000 rw- 15c800000-15d000000 rw- 15d000000-15d800000 rw- 15d800000-15e000000 rw- 15e000000-15e800000 rw- 15e800000-15f000000 rw- 15f000000-15f800000 rw- 15f800000-160000000 rw- 167b08000-16b30c000 --- 16b30c000-16bb08000 rw- 16bb08000-16bb0c000 --- 16bb0c000-16bb94000 rw- 16bb94000-16bb98000 --- 16bb98000-16bda0000 rw- 16bda0000-16bda4000 --- 16bda4000-16bfac000 rw- 16bfac000-16bfb0000 --- 16bfb0000-16c1b8000 rw- 180000000-190000000 r-- 190000000-1a0000000 r-- 1a0000000-1b0000000 r-- 1b0000000-1c0000000 r-- 1c0000000-1d0000000 r-- 1d0000000-1e0000000 r-- 1e0000000-1e6000000 r-- 1e6000000-1e6e2c000 r-- 1e6e2c000-1e8000000 rw- 1e8000000-1f0000000 r-- 1f0000000-1f2000000 r-- 1f2000000-1f2bcc000 r-- 1f2bcc000-1f4864000 rw- 1f4864000-1f6000000 r-- 1f6000000-1f6864000 r-- 1f6864000-1fa57c000 r-- 1fa57c000-1fc000000 r-- 1fc000000-200000000 r-- 200000000-210000000 r-- 210000000-220000000 r-- 220000000-230000000 r-- 230000000-240000000 r-- 240000000-250000000 r-- 250000000-260000000 r-- 260000000-270000000 r-- 270000000-280000000 r-- fc0000000-1000000000 --- 1000000000-7000000000 --- [IMPORTANT] Don't forget to include the Crash Report log file under DiagnosticReports directory in bug reports. Abort trap: 6 ``` ---Files-------------------------------- ruby_2021-07-06-231613_Moris-Macbook-Air.crash (35.9 KB) ruby_2021-08-24-203317_Moris-Macbook-Air.crash (17.4 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-dev:52014] [Ruby master Feature#19194] Add Regexp.linear_time?
by make_now_just (Hiroya Fujinami) 25 Dec '22

25 Dec '22

Issue #19194 has been reported by make_now_just (Hiroya Fujinami). ---------------------------------------- Feature #19194: Add Regexp.linear_time? https://bugs.ruby-lang.org/issues/19194 * Author: make_now_just (Hiroya Fujinami) * Status: Open * Priority: Normal ---------------------------------------- I suggest adding a new method named `Regexp.linear_time?` to check if matching against a given regexp can be completed in linear time by the optimization introduced in #19104 (GitHub PR [#6486](https://github.com/ruby/ruby/pull/6486)). This method was discussed in #19104. I'm not sure the name is best. # Example ``` Regexp.linear_time?(/a/) # => true Regexp.linear_time?(/(a|a)*\1/) # => false, because this uses a back-reference. # This can accept a regexp source string and flags like `Regexp.new`. Regexp.linear_time?('a') # => true Regexp.linear_time?('a', Regexp::IGNORECASE) # => true ``` For example, this method is useful for implementing a Rubocop rule to check a regexp is ReDoS safe. # Implementation Implementation is done at GitHub PR [#6901](https://github.com/ruby/ruby/pull/6901). See the details there. -- https://bugs.ruby-lang.org/

5 9

[ruby-dev:52013] [Ruby master Feature#19193] drop DOS TEXT mode support
by YO4 (Yoshinao Muramatsu) 20 Dec '22

20 Dec '22

Issue #19193 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Feature #19193: drop DOS TEXT mode support https://bugs.ruby-lang.org/issues/19193 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Priority: Normal ---------------------------------------- On Windows platform, ```File.open(path, "r")``` returns an object different from "rt" and "rb". I call that DOS TEXT mode here. DOS TEXT mode does * crlf conversion * 0x1a treated EOF charactor on read and others (see Bug #19192). But DOS TEXT mode is almost unnecessary today and it seems to introduce lot of code complexities. Now there is less need for dos text mode * Microsoft's most apps works without CRLF newline. * Creating a crlf text file today should be explicit. (but that is default mode on windows now) * Interpreting EOF charactor can cause trouble. I think it's time to consider dropping DOS TEXT mode. What challenges are there and what preparation is needed? -- https://bugs.ruby-lang.org/

3 3

[ruby-dev:52028] [Ruby master Feature#19134] ** is not allowed in def foo(...)
by Eregon (Benoit Daloze) 15 Dec '22

15 Dec '22

Issue #19134 has been updated by Eregon (Benoit Daloze). shugo (Shugo Maeda) wrote in #note-14: > Speaking of implicity of blocks, `def f; g(&); end` causes a syntax error, so it may be better to allow it, or disallow `def f(...); g(&); end` in the future versions. Since some time @ko1 worked on no implicit block if not a parameter of the method (with the exception of `yield` in the body). I think that's a good property, so I think it's good for `def f; g(&); end` to be a syntax error. For `def f(...); g(&); end` "..." is "capture all arguments, positional, keyword and block" so I think it's more natural there to be able to access the block (although I can't think of when that would be useful, maybe `def f(...); g(&); h(...) end` when `h` is known to ignore the block but that feels hacky, better use `(*, **, &)` parameters then). > Anyway, I've fixed the behavior of `...` as described in #note-9. Thanks! ---------------------------------------- Feature #19134: ** is not allowed in def foo(...) https://bugs.ruby-lang.org/issues/19134#change-100680 * Author: shugo (Shugo Maeda) * Status: Closed * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) * Target version: 3.2 ---------------------------------------- `*` and `&` are allowed in the body of a method with `...` argument forwarding, but `**` is not allowed. ``` def foo(...) bar(*) # OK baz(&) # OK quux(**) # NG end ``` Is it intended behavior? It seems that parse.y has code like `#ifdef RUBY3_KEYWORDS`, and if RUBY3_KEYWORDS, `**` will also be supported. -- https://bugs.ruby-lang.org/

1 0