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

[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:121136] [Ruby master Bug#21151] IO and StringIO raise FrozenError even for read-only methods
by headius (Charles Nutter) 13 Mar '25

13 Mar '25

Issue #21151 has been reported by headius (Charles Nutter). ---------------------------------------- Bug #21151: IO and StringIO raise FrozenError even for read-only methods https://bugs.ruby-lang.org/issues/21151 * Author: headius (Charles Nutter) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Problem -------- While fixing a small [regression](https://github.com/ruby/stringio/issues/119) from my recent StringIO [fixes](https://github.com/ruby/stringio/issues/116) I discovered that a large number of read-only methods will fail if the StringIO is frozen. A few examples: ``` $ ruby -rstringio -e 's = StringIO.new; p s.lineno; s.freeze; p s.lineno' 0 -e:1:in 'StringIO#lineno': can't modify frozen StringIO: #<StringIO:0x0000000103711ea8> (FrozenError) from -e:1:in '<main>' $ ruby -rstringio -e 's = StringIO.new; p s.closed?; s.freeze; p s.closed?' false -e:1:in 'StringIO#closed?': can't modify frozen StringIO: #<StringIO:0x00000001008c1e68> (FrozenError) from -e:1:in '<main>' $ ruby -rstringio -e 's = StringIO.new; p s.eof?; s.freeze; p s.eof?' true -e:1:in 'StringIO#eof?': can't modify frozen StringIO: #<StringIO:0x000000011c171e80> (FrozenError) from -e:1:in '<main>' $ ruby -rstringio -e 's = StringIO.new; p s.pos; s.freeze; p s.pos' 0 -e:1:in 'StringIO#pos': can't modify frozen StringIO: #<StringIO:0x0000000105551df0> (FrozenError) from -e:1:in '<main>' ``` @kou pointed out that IO also raises for at least `lineno` and suggested I re-open the issue here. I still believe these read-only operations should be allowed on frozen IO or StringIO. Cause in StringIO ----------------- This is because the `StringIO` macro calls `get_strio` which calls `rb_io_taint_check` which calls `rb_check_frozen`. The `StringIO` macro is used in almost every method to access the rb_stringio_t data structure. A list of methods I believe should be operable when the StringIO is frozen (in stringio.c definition order): * string (returns underlying String but does not mutate anything) * lineno * pos * closed?/closed_read?/closed_write? * eof/eof? * sync * pid (a dummy method but it writes nothing) * fileno (dummy) * pread (by definition does not modify state) * isatty/tty? * size/length * external_encoding * internal_encoding In addition, `initialize_copy` probably should not require the original StringIO to be writable: ``` $ ruby -rstringio -e 's = StringIO.new("foo"); s.freeze; p s.dup' -e:1:in 'StringIO#initialize_copy': can't modify frozen StringIO: #<StringIO:0x0000000102eb1df8> (FrozenError) from -e:1:in 'Kernel#initialize_dup' from -e:1:in 'Kernel#dup' from -e:1:in '<main>' ``` The data from the original StringIO is unmodified by `initialize_copy`, other than the reference-counting `ptr->count` (which should not be subject to frozen checks). Cause in IO ----------- The `GetOpenFile` macro calls `RB_IO_POINTER` macro which calls `rb_io_taint_check` which calls `rb_check_frozen`. Methods in IO that should work on a frozen IO include any of the above StringIO that currently raise. For example `lineno` uses `GetOpenFile`, but `fileno` does not and does not raise. There's clearly some inconsistency here we can clean up. Origin ------ I believe most of the StringIO cases are caused by this change from 2011 that added frozen checks to StringIO (the class and the macro): https://github.com/ruby/ruby/commit/d8d9bac5c8b071135e50ad3f21c8a9b6a9c06e54 In IO, this behavior dates way back to 2000 by @matz himself: https://github.com/ruby/ruby/commit/087c83d7ceed6893afff93066937fb570ae4a115 Notes ----- I have started to fix the StringIO cases for JRuby in https://github.com/ruby/stringio/pull/122. I could probably fix the C version of StringIO as well, but I'm a little more unsure about how to fix IO. -- https://bugs.ruby-lang.org/

3 2

[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

[ruby-core:112301] [Ruby master Bug#19426] Endless `Range#step` of object with `#succ` method does not work
by nobu (Nobuyoshi Nakada) 13 Mar '25

13 Mar '25

Issue #19426 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19426: Endless `Range#step` of object with `#succ` method does not work https://bugs.ruby-lang.org/issues/19426 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Consider this `c` object which hash `#succ` method. ```ruby c = Struct.new(:i) do def succ; self.class.new(i+1); end def <=>(other) i <=> other.i;end end.new(0) ``` This `Range#step` works. ```ruby (c..c.succ).step(1) do |d| p d.i # 0, 1 end ``` But it fails on an endless range. ```ruby (c..).step(1) do |d| p d.i break if d.i > 3 end ``` ``` -:3:in `<=>': undefined method `i' for nil:NilClass (NoMethodError) from -:10:in `step' from -:10:in `<main>' ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:120637] [Ruby master Bug#21032] `Module#autoload?` is slow when `$LOAD_PATH` contains a relative path
by byroot (Jean Boussier) 13 Mar '25

13 Mar '25

Issue #21032 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21032: `Module#autoload?` is slow when `$LOAD_PATH` contains a relative path https://bugs.ruby-lang.org/issues/21032 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.1: WONTFIX, 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- Reproduction script: ```ruby require 'benchmark' $LOAD_PATH << 'relative-path' autoload :FOO, '/tmp/foo.rb' puts Benchmark.realtime { 500_000.times do Object.autoload?(:FOO) end } ``` The above takes 2.5 to 3 seconds on my machine, but just removing `$LOAD_PATH << 'relative-path'` make it complete in 50ms. It's such a stark difference that I think it is a bug, and it cause Zeitwerk, a very popular gem, to be way slower than it should when the load path contains relative paths. I have a patch for it, that passes all tests, but I'd appreciate some eyes on it: https://github.com/ruby/ruby/pull/12562 cc @fxn -- https://bugs.ruby-lang.org/

5 8