- ruby-core - ml.ruby-lang.org

[ruby-core:123162] [Ruby Feature#17398] SyntaxError in endless method
by mame (Yusuke Endoh) 01 Sep '25

01 Sep '25

Issue #17398 has been updated by mame (Yusuke Endoh). Status changed from Open to Assigned Assignee set to prism Ok, then we need a patch for prism ---------------------------------------- Feature #17398: SyntaxError in endless method https://bugs.ruby-lang.org/issues/17398#change-114500 * Author: zverok (Victor Shepelev) * Status: Assigned * Assignee: prism ---------------------------------------- This works: ```ruby def foo() = puts("bar") ``` This does not: ```ruby def foo() = puts "bar" # ^ syntax error, unexpected string literal, expecting `do' or '{' or '(' ``` Is this intentional or accidental? Not sure how it is reasoned. ---Files-------------------------------- allow-command-style-endless-method-def.patch (3.44 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123161] [Ruby Feature#17398] SyntaxError in endless method
by matz (Yukihiro Matsumoto) 01 Sep '25

01 Sep '25

Issue #17398 has been updated by matz (Yukihiro Matsumoto). Sounds reasonable, considering existing grammar. Matz. ---------------------------------------- Feature #17398: SyntaxError in endless method https://bugs.ruby-lang.org/issues/17398#change-114499 * Author: zverok (Victor Shepelev) * Status: Open ---------------------------------------- This works: ```ruby def foo() = puts("bar") ``` This does not: ```ruby def foo() = puts "bar" # ^ syntax error, unexpected string literal, expecting `do' or '{' or '(' ``` Is this intentional or accidental? Not sure how it is reasoned. ---Files-------------------------------- allow-command-style-endless-method-def.patch (3.44 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123141] [Ruby Bug#21558] Regexp.union with multiple regexps returns a non-shareable object (should be shareable if possible)
by niku (niku _) 01 Sep '25

01 Sep '25

Issue #21558 has been reported by niku (niku _). ---------------------------------------- Bug #21558: Regexp.union with multiple regexps returns a non-shareable object (should be shareable if possible) https://bugs.ruby-lang.org/issues/21558 * Author: niku (niku _) * Status: Open * ruby -v: ruby 3.5.0dev (2025-08-30T18:24:25Z master 5c7dfe85a1) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Regexp.union returns a non-shareable object when given multiple Regex arguments. Is this expected behavior? It would be preferable if the resulting Regexp were shareable, since single-argument `Regexp.union` does produce a shareable object. ```irb irb(main):001> a = /a/ => /a/ irb(main):002> b = Regexp.union(a) => /a/ irb(main):003> c = Regexp.union(a, a) => /(?-mix:a)|(?-mix:a)/ irb(main):004> Ractor.shareable?(a) => true irb(main):005> Ractor.shareable?(b) => true irb(main):006> Ractor.shareable?(c) => false ``` -- https://bugs.ruby-lang.org/

3 5

[ruby-core:123153] [Ruby Feature#17398] SyntaxError in endless method
by mame (Yusuke Endoh) 31 Aug '25

31 Aug '25

Issue #17398 has been updated by mame (Yusuke Endoh). Status changed from Closed to Open Thanks, it looks good. @matz what do you think? ---------------------------------------- Feature #17398: SyntaxError in endless method https://bugs.ruby-lang.org/issues/17398#change-114485 * Author: zverok (Victor Shepelev) * Status: Open ---------------------------------------- This works: ```ruby def foo() = puts("bar") ``` This does not: ```ruby def foo() = puts "bar" # ^ syntax error, unexpected string literal, expecting `do' or '{' or '(' ``` Is this intentional or accidental? Not sure how it is reasoned. ---Files-------------------------------- allow-command-style-endless-method-def.patch (3.44 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123152] [Ruby Feature#17398] SyntaxError in endless method
by yui-knk (Kaneko Yuichiro) 31 Aug '25

31 Aug '25

Issue #17398 has been updated by yui-knk (Kaneko Yuichiro). > Note that private def hello = puts "Hello" does not parse for technical reason. It's possible. Patch is https://github.com/yui-knk/ruby/tree/bug_17398. This change allows single endless method definition with command body as an argument of the method. Some cases you might be aware are * `private :m, def hello = puts "Hello"` * This is SyntaxError because only single argument case is allowed. * This is same with one command is passed to argument. `obj.m 0, cmd 1, 2` is SyntaxError. * `private def hello = puts "Hello", "World"` * This is interpreted as `private def hello = puts("Hello", "World")` not `private (def hello = puts "Hello"), "World"`. * This is same with one command is passed to argument. `obj.m cmd 1, 2` is interpreted as `obj.m cmd(1, 2)` not `obj.m (cmd 1), 2`. * `private def hello = puts "Hello" do expr end` * This is interpreted as `private (def hello = puts "Hello") do expr end` not `private (def hello = puts "Hello" do expr end)` * This is same with one command is passed to argument. `obj.m cmd 1, 2 do expr end` is interpreted as `obj.m (cmd 1, 2) do expr end` not `obj.m (cmd 1, 2 do expr end)` ---------------------------------------- Feature #17398: SyntaxError in endless method https://bugs.ruby-lang.org/issues/17398#change-114484 * Author: zverok (Victor Shepelev) * Status: Closed ---------------------------------------- This works: ```ruby def foo() = puts("bar") ``` This does not: ```ruby def foo() = puts "bar" # ^ syntax error, unexpected string literal, expecting `do' or '{' or '(' ``` Is this intentional or accidental? Not sure how it is reasoned. ---Files-------------------------------- allow-command-style-endless-method-def.patch (3.44 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123151] [Ruby Bug#18878] parse.y: Foo::Bar {} is inconsistently rejected
by yui-knk (Kaneko Yuichiro) 31 Aug '25

31 Aug '25

Issue #18878 has been updated by yui-knk (Kaneko Yuichiro). Note: 9930363aab6ac4b8d7034baff85cd86c17953dc9 was the commit to allow `Foo::Bar {}` in parse.y. ---------------------------------------- Bug #18878: parse.y: Foo::Bar {} is inconsistently rejected https://bugs.ruby-lang.org/issues/18878#change-114483 * Author: qnighy (Masaki Hara) * Status: Assigned * Assignee: ydah (Yudai Takada) * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- The following source doesn't parse: ```ruby Foo::Bar {} ``` despite the following: ```ruby bar # local variable or method call Bar # constant bar() # method call Bar() # method call bar {} # method call Bar {} # method call bar() {} # method call Bar() {} # method call Foo::bar # method call Foo::Bar # constant Foo::bar() # method call Foo::Bar() # method call Foo::bar {} # method call # Foo::Bar {} # SyntaxError Foo::bar() {} # method call Foo::Bar() {} # method call ``` Especially considering `Bar {}`, this looks like a missing implementation rather than an intentional behavior. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123150] [Ruby Bug#18878] parse.y: Foo::Bar {} is inconsistently rejected
by yui-knk (Kaneko Yuichiro) 31 Aug '25

31 Aug '25

Issue #18878 has been updated by yui-knk (Kaneko Yuichiro). Patch: * Support only `Foo::Bar {} + 1`: https://github.com/yui-knk/ruby/tree/bug_18878_2 * Support both `Foo::Bar {} + 1` and `Foo::Bar do end` (and `Foo::Bar do end + 1`): https://github.com/yui-knk/ruby/tree/bug_18878 ---------------------------------------- Bug #18878: parse.y: Foo::Bar {} is inconsistently rejected https://bugs.ruby-lang.org/issues/18878#change-114482 * Author: qnighy (Masaki Hara) * Status: Assigned * Assignee: ydah (Yudai Takada) * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- The following source doesn't parse: ```ruby Foo::Bar {} ``` despite the following: ```ruby bar # local variable or method call Bar # constant bar() # method call Bar() # method call bar {} # method call Bar {} # method call bar() {} # method call Bar() {} # method call Foo::bar # method call Foo::Bar # constant Foo::bar() # method call Foo::Bar() # method call Foo::bar {} # method call # Foo::Bar {} # SyntaxError Foo::bar() {} # method call Foo::Bar() {} # method call ``` Especially considering `Bar {}`, this looks like a missing implementation rather than an intentional behavior. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123021] [Ruby Misc#21549] DevMeeting-2025-09-11
by mame (Yusuke Endoh) 30 Aug '25

30 Aug '25

Issue #21549 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21549: DevMeeting-2025-09-11 https://bugs.ruby-lang.org/issues/21549 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/09/11 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/09/08. 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/

4 3

[ruby-core:123042] [Ruby Feature#21550] Ractor.sharable_proc/sharable_lambda to make sharable Proc object
by ko1 (Koichi Sasada) 30 Aug '25

30 Aug '25

Issue #21550 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #21550: Ractor.sharable_proc/sharable_lambda to make sharable Proc object https://bugs.ruby-lang.org/issues/21550 * Author: ko1 (Koichi Sasada) * Status: Open * Assignee: ko1 (Koichi Sasada) * Target version: 3.5 ---------------------------------------- Let's introduce a way to make a sharable Proc. * `Ractor.shareable_proc(self: nil, &block)` makes proc. * `Ractor.shareable_lambda(self: nil, &block)` makes lambda. See also: https://bugs.ruby-lang.org/issues/21039 ## Background ### Motivation Being able to create a shareable Proc is important for Ractors. For example, we often want to send a task to another Ractor: ```ruby worker = Ractor.new do while task = Ractor.receive task.call(...) end end task = (sharable_proc) worker << task task = (sharable_proc) worker << task task = (sharable_proc) worker << task ``` There are various ways to represent a task, but using a Proc is straightforward. However, to make a Proc shareable today, self must also be shareable, which leads to patterns like: ```ruby nil.instance_eval{ Proc.new{ ... } } ``` This is noisy and cryptic. We propose dedicated methods to create shareable Proc objects directly. ## Specification * `Ractor.shareable_proc(self: nil, &block)` makes a proc. * `Ractor.shareable_lambda(self: nil, &block)` makes a lambda. Both methods create the Proc/lambda with the given self and make the resulting object shareable. Captured outer variables follow the current `Ractor.make_shareable` semantics: * If a captured outer local variable refers to a shareable object, a shareable Proc may read it. * If any captured outer variable refers to a non‑shareable object, creating the shareable Proc raises an error. ```ruby a = 42 b = "str" Ractor.sharalbe_proc{ p a #=> 42 } Ractor.sharalbe_proc{ # error when making a sharealbe proc p b #=> 42 } ``` * The captured outer local variables are copied by value when the shareable Proc is created. Subsequent modifications of those variables in the creator scope do not affect the Proc. ``` a = 42 shpr = Ractor.sharable_proc{ p a } a = 0 shpr.call #=> 42 ``` ``` * Assigning to outer local variables from within the shareable Proc is not allowed (error at creation). ```ruby a = 42 Ractor.shareable_proc{ # error when making a sharealbe proc a = 43 } ``` More about outer-variable handling are discussed below. In other words, from the perspective of a shareable Proc, captured outer locals are read‑only constants. This proposal does not change the semantics of Ractor.make_shareable() itself. ## Discussion about outer local variables [Feature #21039] discusses how captured variables should be handled. I propose two options. ### 1. No problem to change the @Eregon noted that the current behavior of `Ractor.make_shareable(proc_obj)` can surprise users. While that is understandable, Ruby already has similar *surprises*. For instance: ```ruby RSpec.describe 'foo' do p self #=> RSpec::ExampleGroups::Foo end ``` Here, `self` is implicitly replaced, likely via `instance_exec`. This can be surprising if one does not know self can change, yet it is accepted in Ruby. We view the current situation as a similar kind of surprise. ### 2. Enforce a strict rule for non‑lexical usage The difficulty is that it is hard to know which block will become shareable unless it is lexically usage. ```ruby # (1) On this code, it is clear that the block will be shareable block: a = 42 Ractor.sharable_proc{ p a } # (2) On this code, it is not clear that the block becomes sharable or not get path do p a end # (3) On this code, it has no problem because get '/hello' do "world" end ``` The idea is to allow accessing captured outer variables only for lexically explicit uses of `Ractor.shareable_proc` as in (1), and to raise an error for non‑lexical cases as in (2). So the example (3) is allowed if the block becomes sharable or not. The strict rule is same as `Ractor.new` block rule. -- https://bugs.ruby-lang.org/

4 15

[ruby-core:122945] [Ruby Bug#21538] initialize_dup not called when duping class/module
by chucke (Tiago Cardoso) 29 Aug '25

29 Aug '25

Issue #21538 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #21538: initialize_dup not called when duping class/module https://bugs.ruby-lang.org/issues/21538 * Author: chucke (Tiago Cardoso) * Status: Open * ruby -v: 3.4.5 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Not sure whether this is expected behaviour or not, but just leaving it here to start the debate on whether callbacks like `initialize_dup` are supposed to be called when a module or class is duped (the same happens with `initialize_copy` and `initialize_clone` btw): class A def initialize_dup(_) puts "dup instance" super end def self.initialize_dup(_) puts "dup class" super end end A.new.dup #=> "dup instance" A.dup #=> nothing -- https://bugs.ruby-lang.org/

2 2