September 2023 - ruby-dev - ml.ruby-lang.org

[ruby-dev:52034] [Ruby master Bug#19792] arm の alpine 上でネストしたハッシュに長い文字列を入れると segmentation fault が発生する

by koke2y

Issue #19792 has been reported by koke2y (優樹纐纈). ---------------------------------------- Bug #19792: arm の alpine 上でネストしたハッシュに長い文字列を入れると segmentation fault が発生する https://bugs.ruby-lang.org/issues/19792 * Author: koke2y (優樹纐纈) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) +YJIT [aarch64-linux-musl] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ## 実行環境 Docker version: Docker version 24.0.2, build cb74dfc Docker image: ruby:3.2.2-alpine3.18 ホスト環境 - chip: Apple M2 Max - OS version: Version 13.4 ## 発生した事象上記の環境で下記のスクリプトを実行すると、segmentation faultが発生しました。 ``` str = 'a' * 100_000_000 hash = { x: { y: { z: str } } } p hash ``` ``` 81a3dc0d38e8:/api# ruby test.rb test.rb:11: [BUG] Segmentation fault at 0x0000ffff84e454a0 ruby 3.2.2 (2023-03-30 revision e51014f9c0) +YJIT [aarch64-linux-musl] -- Control frame information ----------------------------------------------- c:0006 p:---- s:0022 e:000021 CFUNC :inspect c:0005 p:---- s:0019 e:000018 CFUNC :inspect c:0004 p:---- s:0016 e:000015 CFUNC :inspect c:0003 p:---- s:0013 e:000012 CFUNC :p c:0002 p:0029 s:0008 E:001cc0 EVAL test.rb:11 [FINISH] c:0001 p:0000 s:0003 E:000da0 DUMMY [FINISH] ``` -- https://bugs.ruby-lang.org/

7 months

5
5
0 0

[ruby-dev:52045] [Ruby master Bug#19902] strftimeの返り値のascii_only?が間違っていることがある

by znz (Kazuhiro NISHIYAMA)

Issue #19902 has been reported by znz (Kazuhiro NISHIYAMA). ---------------------------------------- Bug #19902: strftimeの返り値のascii_only?が間違っていることがある https://bugs.ruby-lang.org/issues/19902 * Author: znz (Kazuhiro NISHIYAMA) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [aarch64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ruby-jp slack で tompng さんの調査によると以下のように `Regexp.esacpe` が変になる原因は `t.ascii_only? #=> true` になっていることでした。 ``` irb(main):053> t = Time.now.strftime(u='あ') => "あ" irb(main):054> t==u => true irb(main):055> t.encoding==u.encoding => true irb(main):056> Regexp.escape(t) => "\xE3\x81\x82" irb(main):057> Regexp.escape(u) => "あ" ``` git bisect で `make miniruby && ./miniruby -ve "p Time.now.strftime('%Y年').ascii_only?"` をしつつ調べてみると、https://github.com/ruby/ruby/commit/f34280ec6b684eeb21ef3336c700… から `true` になってしまっているようです。 -- https://bugs.ruby-lang.org/

7 months

4
3
0 0

[ruby-dev:52044] [Ruby master Bug#17925] Pattern matching syntax using semicolon one-line

by kddnewton (Kevin Newton)

Issue #17925 has been updated by kddnewton (Kevin Newton). I agree with @yui-knk here, I think this is definitely a choice and at this point can't be changed. ---------------------------------------- Bug #17925: Pattern matching syntax using semicolon one-line https://bugs.ruby-lang.org/issues/17925#change-104733 * 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/

7 months, 1 week

1
0
0 0

[ruby-dev:52043] [Ruby master Bug#17925] Pattern matching syntax using semicolon one-line

by yui-knk (Kaneko Yuichiro)

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/

7 months, 3 weeks

1
0
0 0

2024

2023

2022

ruby-dev September 2023

2024

2023

2022

ruby-dev September 2023 ----- 2024 ----- April 2024 March 2024 February 2024 January 2024 ----- 2023 ----- December 2023 November 2023 October 2023 September 2023 August 2023 July 2023 June 2023 May 2023 April 2023 March 2023 February 2023 January 2023 ----- 2022 ----- December 2022 November 2022

ruby-dev September 2023