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

[ruby-core:122235] [Ruby Feature#21361] Set execution file and line
by kddnewton (Kevin Newton) 03 Jun '25

03 Jun '25

Issue #21361 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #21361: Set execution file and line https://bugs.ruby-lang.org/issues/21361 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- I'd like to be able to set the execution file and execution line for the purpose of generated Ruby code. My specific use case is the Ruby files that are templated in Prism, but I also believe it would be beneficial for ERB. The functionality I'm looking for effectively mirrors the `#line` macro in C. The goal would be for this to be entirely statically analyzable, so whatever syntax ends up being used would have to be required to be constant. A couple of options for this would be: * An entirely new syntax construct (`__SOURCE__ 5 "foo.erb"`) * Re-using existing syntax constructs (`__LINE__ = 5; __FILE__ = "foo.erb"`) * A magic comment (`# -*- source-line: 5; source-file: foo.erb -*-` or `# source: 5 foo.erb`) I don't particularly care which one is selected, it's just the end-result that I'm looking for that we can mark the source line and file within the generated code. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122042] [Ruby Bug#21330] Namespace: Class and Module frozen status is not namespace
by byroot (Jean Boussier) 03 Jun '25

03 Jun '25

Issue #21330 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21330: Namespace: Class and Module frozen status is not namespace https://bugs.ruby-lang.org/issues/21330 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby File.write("/tmp/test.rb", <<~'RUBY') Hash.freeze RUBY ns = Namespace.new ns.require("/tmp/test.rb") class Hash def monkey_patch end end ``` Expected behavior: Since the monkey patch is in a different namespace, I'd expect it to not impact code that is running in another namespace. Actual behavior: ``` test.rb:9:in '<class:Hash>': can't modify frozen class: Hash (FrozenError) ``` The class is frozen globally, breaking code in other namespaces. Is this by design, or does that mean the frozen status need to be moved in the `classext_t` as well? cc @tagomoris -- https://bugs.ruby-lang.org/

4 4

[ruby-core:122350] [Ruby Feature#21387] Proposal to add Data#[]
by ybiquitous (Masafumi Koba) 02 Jun '25

02 Jun '25

Issue #21387 has been reported by ybiquitous (Masafumi Koba). ---------------------------------------- Feature #21387: Proposal to add Data#[] https://bugs.ruby-lang.org/issues/21387 * Author: ybiquitous (Masafumi Koba) * Status: Open ---------------------------------------- ## Proposal I propose to add a new instance method `#[]` to the `Data` class, similar to [`Struct#[]`](https://docs.ruby-lang.org/en/3.4/Struct.html#method-i-5B-5D). If writing the method signature in RBS, it would be like this: ```ruby class Data def []: (name: String | Symbol) -> untyped end ``` Requirements: - `Data#[]` accepts a member name as a `Symbol` or `String`, e.g., `data[:id] == data["id"]`. - `Data#[]` returns a value associated with the given `name`, e.g., `data[:id] == data.id`. - `Data#[]` raises `NameError` if the given `name` is not one of the members, e.g., `data[:invalid]`. Note: Please assume that `data = Data.define(:id).new(id: 100)` is given in the examples above. ## Motivation In Active Support Core Extensions of Rails, I found a use case that `Data#[]` would be helpful with `Enumerable#pluck`. Please look at this example: ```ruby # data_test.rb require "bundler/inline" gemfile do source "https://rubygems.org" gem "activesupport", "8.0.2" end require "active_support/core_ext/enumerable" StructPerson = Struct.new(:name, :age) DataPerson = Data.define(:name, :age) struct_people = [ StructPerson.new("Bob", 25), ] puts "Struct:" puts "=> #{struct_people.pluck(:name)}" data_people = [ DataPerson.new("Charlie", 35), ] puts "Data:" begin puts "=> #{data_people.pluck(:name)}" rescue => e puts e.detailed_message(syntax_suggest: true) end ``` Running this script outputs below: ```shell $ ruby data_test.rb Struct: => ["Bob"] Data: undefined method '[]' for an instance of DataPerson (NoMethodError) map { |element| element[key] } ^^^^^ ``` Note: This output resulted on `ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [arm64-darwin24]`. The error reason is that the `Enumerable#pluck` extension expects all the elements in the array to respond to `[]`. See also the `pluck` code here: https://github.com/rails/rails/blob/v8.0.2/activesupport/lib/active_support… If `Data#[]` was implemented as follows, ```ruby # data_patch.rb class Data def [](name) unless members.include?(name.to_sym) raise NameError, "no member '#{name}' in data" end public_send(name) end end ``` The script is successful: ```shell $ ruby -r ./data_patch.rb data_test.rb Struct: => ["Bob"] Data: => ["Charlie"] ``` Ref: - https://guides.rubyonrails.org/v8.0.2/active_support_core_extensions.html#p… - https://api.rubyonrails.org/v8.0.2/classes/Enumerable.html#method-i-pluck Although `Enumerable#pluck` is just an example, I guess that there would be other cases where `Data` objects should respond to `[]`. ## Reasoning From the long discussion in #16122 that introduced `Data`, I understand that `Data#[]` was rejected in #16122#note-28 because `[]` was like `Enumerable`. I also agree with rejecting `Data#each` since `Data` is not an `Enumerable`, but `[]` seems acceptable to me. Reasons: - `[]` is sometimes used for non-container objects, such as [`ActiveRecord::AttributeMethods#[]`](https://api.rubyonrails.org/v8.0.2/classes/ActiveRecord/AttributeMethods.html#method-i-5B-5D). - Considering `Data#to_h` is provided, it seems reasonable that we could access a `Data` member's value through `[]`. - From the similarity between `Struct` and `Data`, some people might expect `Hash`-like accessing via `[]`. - Unless `[]` is provided, we have to call `public_send` or convert to a hash via `to_h` when we want to get member values with names. It'd be inefficient and easy to make mistakes. Let me show an example: ```ruby Person = Data.define(:name, :age) charlie = Person.new("Charlie", 35) member_names_from_user_input = ["age", "hash"] # "hash" is a malicious input. # Using #public_send member_names_from_user_input.map { charlie.public_send(it) } #=> [35, -1363726049241242821] # Using #to_h and Hash#fetch with string keys member_names_from_user_input.map { charlie.to_h.fetch(it) } #=> key not found: "age" (KeyError) # Using #to_h and Hash#fetch with symbol keys member_names_from_user_input.map { charlie.to_h.fetch(it.to_sym) } #=> key not found: :hash (KeyError) # Using #[] member_names_from_user_input.map { charlie[it] } #=> no member 'hash' in data (NameError) ``` The last example is most elegant for the same goal. That's why I propose to add `Data#[]`. However, there might be downsides that I have overlooked, so I'd appreciate it if you could let me know. Thanks. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:122321] [Ruby Misc#21379] DevMeeting-2025-06-05
by hsbt (Hiroshi SHIBATA) 02 Jun '25

02 Jun '25

Issue #21379 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Misc #21379: DevMeeting-2025-06-05 https://bugs.ruby-lang.org/issues/21379 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/06/05 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/05/05. 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/

6 5

[ruby-core:122289] [Ruby Bug#21372] Ruby is passing clang specific flags to GCC 15 and native gem doesn't build.
by skatkov (Stanislav (Stas) Katkov) 28 May '25

28 May '25

Issue #21372 has been reported by skatkov (Stanislav (Stas) Katkov). ---------------------------------------- Bug #21372: Ruby is passing clang specific flags to GCC 15 and native gem doesn't build. https://bugs.ruby-lang.org/issues/21372 * Author: skatkov (Stanislav (Stas) Katkov) * Status: Open * ruby -v: ruby 3.4.4 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Fedora 42 has ompilation errors while running `gem install extlz4`. ```sh At top level: cc1: note: unrecognized command-line option ‘-Wno-self-assign’ may have been intended to silence earlier diagnostics cc1: note: unrecognized command-line option ‘-Wno-parentheses-equality’ may have been intended to silence earlier diagnostics cc1: note: unrecognized command-line option ‘-Wno-constant-logical-operand’ may have been intended to silence earlier diagnostics make: *** [Makefile:251: blockapi.o] Error 1 make failed, exit code 2 Gem files will remain installed in /home/sk/.local/share/mise/installs/ruby/3.4.1/lib/ruby/gems/3.4.0/gems/extlz4-0.3.4 for inspection. Results logged to /home/sk/.local/share/mise/installs/ruby/3.4.1/lib/ruby/gems/3.4.0/extensions/x86_64-linux/3.4.0/extlz4-0.3.4/gem_make.out ``` I have submitted a ticket with a gem, but I have hunch that this might not be an issue with a gem, but rather a ruby compatibility issue with the new GCC (15). @see https://github.com/dearblue/ruby-extlz4/issues/6 I have very little experience with C and how compilation works. But as far as I can understand, ruby was compiled with clang and is now passing some CLANG specifics flags to GCC 15 during native gem compilation - this causes a compilation error. ```sh ruby -rrbconfig -e 'puts RbConfig::CONFIG["warnflags"].split(/\s+/).grep(/-Wno-/).sort' -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-packed-bitfield-compat -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value ``` ``` ruby -rrbconfig -e 'system RbConfig::CONFIG["CC"], "--version"' gcc (GCC) 15.1.1 20250521 (Red Hat 15.1.1-2) Copyright (C) 2025 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ``` All my attept to overwrite compiler to use clang don't work either. I tried the following: ``` gem install extlz4 -- --with-cc=clang CC=clang gem install extlz4 CC=/usr/bin/clang gem install extlz4 ``` ## System os: fedora 42 ruby: ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [x86_64-linux] (but also tried it with 3.3.8, with no success) gcc: gcc (GCC) 15.1.1 20250521 (Red Hat 15.1.1-2) ## Workaround I run the following script and then it's possible to complete "bundle install" process. https://gist.github.com/skatkov/df4db6f8b76e58fc8eefaa92592f2c1a -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122306] [Ruby Bug#21377] core Set#inspect does not use inherited class name
by Ethan (Ethan -) 28 May '25

28 May '25

Issue #21377 has been reported by Ethan (Ethan -). ---------------------------------------- Bug #21377: core Set#inspect does not use inherited class name https://bugs.ruby-lang.org/issues/21377 * Author: Ethan (Ethan -) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-26T17:42:35Z master 909a0daab6) +PRISM [x86_64-darwin22] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Following #21216, Set#inspect stopped using self.class.name and just uses 'Set' now. ```ruby class MySet < Set; end MySet.new.inspect # before: #<MySet: {}> # now: #<Set: {}> ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:122258] [Ruby Misc#21367] Remove link to ruby-doc.org from www.ruby-lang.org/en/documentation/
by p8 (Petrik de Heus) 27 May '25

27 May '25

Issue #21367 has been reported by p8 (Petrik de Heus). ---------------------------------------- Misc #21367: Remove link to ruby-doc.org from www.ruby-lang.org/en/documentation/ https://bugs.ruby-lang.org/issues/21367 * Author: p8 (Petrik de Heus) * Status: Open ---------------------------------------- The ruby-doc.org domain no longer seems resolvable. ``` $ curl -I http://ruby-doc.org curl: (6) Could not resolve host: ruby-doc.org ``` The owner of the domain mentioned he wanted to sell it: https://ruby.social/@jamesbritt@mastodon.social/114375521600278606 This is probably a good time to remove it from https://www.ruby-lang.org/en/documentation/. This could also improve SEO for the official documentation. -- https://bugs.ruby-lang.org/

7 10

[ruby-core:122291] [Ruby Bug#21373] "Illegal instruction: 4" when raising SystemStackError after rescuing
by Ethan (Ethan -) 27 May '25

27 May '25

Issue #21373 has been reported by Ethan (Ethan -). ---------------------------------------- Bug #21373: "Illegal instruction: 4" when raising SystemStackError after rescuing https://bugs.ruby-lang.org/issues/21373 * Author: Ethan (Ethan -) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-darwin22] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I overflowed the stack in a test - this was rescued and tests continued, but when the next test also overflowed the stack, instead of handling the exception, ruby exited with "Illegal instruction: 4", exit code 132, and no other output (no stack trace or dump). A minimal reproduction follows. The C method JSON::Ext::Generator::GeneratorMethods::Hash#to_json alternates with X#to_json on the stack; this does not reproduce without the C method. This is on macos and does not reproduce on linux. ```ruby require 'json' class X def to_json(*args) {'data' => self}.to_json(*args) end end # raise and rescue once works fine begin JSON.dump(X.new) rescue SystemStackError end # upon overflowing stack a second time, ruby exits abnormally # with "Illegal instruction: 4" instead of SystemStackError JSON.dump(X.new) ``` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:122277] [Ruby Bug#21371] Proposal to Remove SPARC Architecture Support from Ruby
by ioquatix (Samuel Williams) 26 May '25

26 May '25

Issue #21371 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21371: Proposal to Remove SPARC Architecture Support from Ruby https://bugs.ruby-lang.org/issues/21371 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- We propose removing support for the SPARC architecture from Ruby. SPARC has seen little to no community usage in recent years, and its continued presence in the codebase—particularly through special cases like rb_sparc_flush_register_windows—adds complexity without clear benefit. Removing SPARC support will reduce maintenance overhead and simplify Ruby’s internals. ## Proposal We propose removing all SPARC-specific code from the Ruby source tree, including `rb_sparc_flush_register_windows` and related build system conditionals. This change would be noted in the release documentation and targeted for inclusion in Ruby 4.0. -- https://bugs.ruby-lang.org/

4 9

[ruby-core:121659] [Ruby Bug#21267] respond_to check in Class#allocate is inconsistent
by jhawthorn (John Hawthorn) 26 May '25

26 May '25

Issue #21267 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21267: respond_to check in Class#allocate is inconsistent https://bugs.ruby-lang.org/issues/21267 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `Class#allocate` has an additional `rb_obj_respond_to(klass, rb_intern("allocate"))` check to forbid allocate being called on a class where it has been made private or undefined, even if used via ex. `bind_call`. ``` >> Rational.allocate (irb):1:in '<main>': undefined method 'allocate' for class Rational (NoMethodError) >> Class.instance_method(:allocate).bind_call(Rational) (irb):1:in 'Class#allocate': calling Rational.allocate is prohibited (TypeError) ``` However I don't think this provides any additional protection from users accessing an uninitialized object, as the user can redefine allocate to anything to bypass the check: ``` >> Class.instance_method(:allocate).bind_call(Class.new(Rational) {def self.allocate; end}) => (0/1) ``` Or even override `respond_to_missing?` ``` >> Class.instance_method(:allocate).bind_call(Class.new(Rational) {def self.respond_to_missing? *; true; end}) => (0/1) ``` So I think we should remove this check. For classes that we need to forbid allocation we should use `rb_undef_alloc_func`. The classes I see this used for are: * MatchData * Refinement * Module * Complex * Rational My main motivation is that this check makes `Class#allocate` slow. There are ways we could improve that, but I don't think the check as-is is useful. If there's an alternative, more robust, check we'd like to do instead of simply removing this I'd be happy to implement it. This makes `allocate` ~75% faster. ``` |allocate_no_params | 19.009M| 20.087M| | | -| 1.06x| |allocate_allocate | 20.587M| 35.882M| | | -| 1.74x| ``` https://github.com/ruby/ruby/pull/13116 -- https://bugs.ruby-lang.org/

2 5