March 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:121354] [Ruby master Bug#21184] SyntaxError when combining `in` with inline hash-rocket (`=>`)
by jtannas (Joel Tannas) 14 Mar '25

14 Mar '25

Issue #21184 has been reported by jtannas (Joel Tannas). ---------------------------------------- Bug #21184: SyntaxError when combining `in` with inline hash-rocket (`=>`) https://bugs.ruby-lang.org/issues/21184 * Author: jtannas (Joel Tannas) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I believe the following should be valid syntax but it's throwing a `SyntaxError`: ``` ruby { a: 1 } in { a: 1 } # => true { a: 1 } in { a: Integer } # => true pattern = { "a" => 1 }; { "a" => 1 } in pattern # => true { "a" => 1 } in { "a" => 1 } # => SYNTAX ERROR ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:117188] [Ruby master Bug#20340] Ractor comments not applying to constant targets
by kddnewton (Kevin Newton) 13 Mar '25

13 Mar '25

Issue #20340 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20340: Ractor comments not applying to constant targets https://bugs.ruby-lang.org/issues/20340 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In this example: ```ruby C, = { foo: bar } ``` You get: ``` == disasm: #<ISeq:<main>@test.rb:1 (1,0)-(1,17)> 0000 putobject :foo ( 1)[Li] 0002 putself 0003 opt_send_without_block <calldata!mid:bar, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0005 newhash 2 0007 dup 0008 expandarray 1, 0 0011 putspecialobject 3 0013 setconstant :C 0015 leave ``` But there's no difference from: ```ruby # shareable_constant_value: literal C, = { foo: bar } ``` I would have expected: ``` == disasm: #<ISeq:<main>@test.rb:1 (1,0)-(2,16)> 0000 putobject RubyVM::FrozenCore ( 2)[Li] 0002 putobject :foo 0004 putobject RubyVM::FrozenCore 0006 putself 0007 opt_send_without_block <calldata!mid:bar, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0009 putobject "C" 0011 opt_send_without_block <calldata!mid:ensure_shareable, argc:2, ARGS_SIMPLE> 0013 newhash 2 0015 opt_send_without_block <calldata!mid:make_shareable, argc:1, ARGS_SIMPLE> 0017 dup 0018 expandarray 1, 0 0021 putspecialobject 3 0023 setconstant :C 0025 leave ``` Is this omission intentional? For context, I'm building this in prism and I need to know if I should explicitly disable this behavior. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120611] [Ruby master Bug#21026] `def __FILE__.a; end` should be a syntax error
by Earlopain (Earlopain _) 13 Mar '25

13 Mar '25

Issue #21026 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21026: `def __FILE__.a; end` should be a syntax error https://bugs.ruby-lang.org/issues/21026 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Constants like `__FILE__`, `__LINE__` and `__ENCODING__` are literals and as such you shouldn't be able to defined singleton methods on them. It already doesn't seem to actually do anything: ```rb def __FILE__.a end __FILE__.a #=> undefined method 'a' for an instance of String (NoMethodError) ``` Wrapping it in brackets correctly reports a syntax error: ```rb code.rb:1: syntax error found (SyntaxError) > 1 | def (__FILE__).a | ^~~~~~~~ cannot define singleton method for literals 2 | end ``` The behavior is consistent between prism and parse.y `__ENCODING__` is frozen and so will result in a runtime error. Same for `__LINE__`, and also `__FILE__` with frozen string literals. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:120548] [Ruby master Bug#21016] What should massign with `shareable_constant_value: experimental_everything` freeze?
by nobu (Nobuyoshi Nakada) 13 Mar '25

13 Mar '25

Issue #21016 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21016: What should massign with `shareable_constant_value: experimental_everything` freeze? https://bugs.ruby-lang.org/issues/21016 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Derived from #21010. Even with prism: ```ruby # shareable_constant_value: experimental_everything A, = "" p A.frozen? #=> false ``` This `A` should be frozen? Furthermore: ```ruby # shareable_constant_value: experimental_everything A, a = "A", "a" p A.frozen? #=> false p a.frozen? #=> false ``` Should only `A` be frozen but not `a`? Or massign including a constant can freeze everything? -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120985] [Ruby master Misc#21134] DevMeeting-2025-03-13
by mame (Yusuke Endoh) 13 Mar '25

13 Mar '25

Issue #21134 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21134: DevMeeting-2025-03-13 https://bugs.ruby-lang.org/issues/21134 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/03/13 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2025/03/10. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:121140] [Ruby master Bug#21152] Enumerator's #size returned by Range#reverse_each raises an exception for endless Range
by andrykonchin (Andrew Konchin) 13 Mar '25

13 Mar '25

Issue #21152 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21152: Enumerator's #size returned by Range#reverse_each raises an exception for endless Range https://bugs.ruby-lang.org/issues/21152 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.4.2 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I've noticed a change between 3.3 and 3.4 in a way how `Range#reverse_each` behaves: Ruby 3.3: ```ruby Range.new("a", nil).size # => nil Range.new(1, nil).size # => Infinity Range.new("a", nil).reverse_each.size # => nil Range.new(1, nil).reverse_each.size # => Infinity ``` Ruby 3.4 ```ruby Range.new("a", nil).size # => nil Range.new(1, nil).size # => Infinity Range.new("a", nil).reverse_each.size # can't iterate from NilClass (TypeError) Range.new(1, nil).reverse_each.size # can't iterate from NilClass (TypeError) ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:121327] [Ruby master Feature#16993] Sets: from hash keys using Hash#key_set
by mame (Yusuke Endoh) 13 Mar '25

13 Mar '25

Issue #16993 has been updated by mame (Yusuke Endoh). This was discussed at the dev meeting. @matz wanted to hear more about the use cases for this method first. Also, since Set is currently in a halfway state where it is not fully built-in, a built-in `Hash#key_set` might require a special hack like `Enumerable#to_set`. https://github.com/ruby/ruby/blob/7c88cbb4a6c486348c44be24941f17ef8be6b329/… @akr pointed out the possible consistency issue of `Hash#compare_by_identity`. Since `Hash#transform_values` keeps this `compare_by_identity` flag, the proposed patch will assign a Hash with `compare_by_identity` flag to `@hash` in Set. We will need to review it carefully to make sure it does not break the implicit assumptions of `set.rb`. ---------------------------------------- Feature #16993: Sets: from hash keys using Hash#key_set https://bugs.ruby-lang.org/issues/16993#change-112294 * Author: marcandre (Marc-Andre Lafortune) * Status: Open ---------------------------------------- To create a set from hash keys currently implies a temporary array for all keys, rehashing all those keys and rebuilding a hash. Instead, the hash could be copied and its values set to `true`. ```ruby h = {a: 1} # Now: Set.new(h.keys) # => Set[:a] # After h.key_set # => Set[:a], efficiently. ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118944] [Ruby master Bug#20698] Please backport fix for CVE-2024-43398
by vo.x (Vit Ondruch) 13 Mar '25

13 Mar '25

Issue #20698 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20698: Please backport fix for CVE-2024-43398 https://bugs.ruby-lang.org/issues/20698 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This is similar request to #20667, but since that was already partially done, I have decided to open new ticket -- https://bugs.ruby-lang.org/

4 4

[ruby-core:113153] [Ruby master Bug#19584] Crash in rb_gc_register_address
by peterzhu2118 (Peter Zhu) 13 Mar '25

13 Mar '25

Issue #19584 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #19584: Crash in rb_gc_register_address https://bugs.ruby-lang.org/issues/19584 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/7670 Some C extensions pass a pointer to a global variable to rb_gc_register_address. However, if a GC is triggered inside of rb_gc_register_address, then the object could get swept since it does not exist on the stack. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:115512] [Ruby master Bug#20025] Parsing identifiers/constants is case-folding dependent
by kddnewton (Kevin Newton) 13 Mar '25

13 Mar '25

Issue #20025 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20025: Parsing identifiers/constants is case-folding dependent https://bugs.ruby-lang.org/issues/20025 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When CRuby parses identifiers, it is encoding-dependent. Once the identifier is found, it determines if it starts with a uppercase or lowercase codepoint. This determines if the identifier is a constant or not. The function is charge of this is `rb_sym_constant_char_p`. For non-unicode encodings where the leading byte has the top-bit set, this relies on onigmo's `mbc_case_fold` to determine if it is a constant or not (as opposed to `is_code_ctype`). This works for almost every single codepoint in every encoding, but has one very weird edge case. In the Windows-1253 encoding for the 0xB5 byte, it's the micro sign. The micro sign, when case folded, becomes the uppercase mu character, and then the lowercase mu character, or 0xEC. This means that even though 0xB5 reports itself as being a lowercase codepoint, it gets parsed as a constant. This example might make this more clear: ``` ruby class Context < BasicObject def method_missing(name, *) = :identifier def self.const_missing(name) = :constant end encoding = Encoding::Windows_1253 character = 0xB5.chr(encoding) source = "# encoding: #{encoding.name}\n#{character}\n" result = Context.new.instance_eval(source) puts "#{encoding.name} encoding of 0x#{character.ord.to_s(16).upcase}" puts " [[:alpha:]] => #{character.match?(/[[:alpha:]]/)}" puts " [[:alnum:]] => #{character.match?(/[[:alnum:]]/)}" puts " [[:upper:]] => #{character.match?(/[[:upper:]]/)}" puts " [[:lower:]] => #{character.match?(/[[:lower:]]/)}" puts " parsed as #{result}" ``` this results in the output of: ``` Windows-1253 encoding of 0xB5 [[:alpha:]] => true [[:alnum:]] => true [[:upper:]] => false [[:lower:]] => true parsed as constant ``` To be clear, I don't think the case-folding is incorrect here (and @duerst confirms that it is correct). I believe instead that it is incorrect to use case-folding here to determine if a codepoint is uppercase or not. Note that this only impacts this one codepoint in this one encoding, so I don't believe this is actually a large-scale problem. But I found it surprising, and think we should change it. -- https://bugs.ruby-lang.org/

4 5